On 08/22/2015 06:25 AM, Tomas Vondra wrote:
On 08/21/2015 08:37 PM, Tom Lane wrote:
Tomas Vondra writes:
I also don't think logging just subset of the stats is a lost case.
Sure, we can't know which of the lines are important, but for example
logging just the top-level contexts with a summary
Hi
I found so a set "psql" and "xargs" is pretty strong. But I miss a psql
option for simple returning current database and continuing in pipeline.
What I am doing:
psql postgres -At -c "select datname from pg_database" |
xargs -P 3 -I % psql % -At -c "select current_databe() from
pg_stat_all_ta
On Sun, Aug 23, 2015 at 12:33 PM, Fabien COELHO wrote:
>
> Hello Amit,
>
> I have tried your scripts and found some problem while using avg.py
>> script.
>> grep 'progress:' test_medium4_FW_off.out | cut -d' ' -f4 | ./avg.py
>> --limit=10 --length=300
>> : No such file or directory
>>
>
> I didn'
On Fri, Aug 21, 2015 at 11:25 PM, David Steele wrote:
> In the current scheme, if the standby has not been archiving and then
> gets promoted, won't it try to push the older WAL segments because the
> .done files do not exist in archive_status? Or does the archiver not
> cross timelines?
The seg
David Rowley writes:
> On 24 August 2015 at 12:19, Tom Lane wrote:
>> I am not exactly convinced that this behavior needs to be visible in
>> EXPLAIN output at all, but if it does, it should be a separate field.
> I have to admit I don't much like it either, originally I had this as an
> extra p
On Sun, Aug 23, 2015 at 7:50 AM, Joe Conway wrote:
> 1) The syntax is a bit different than what Andrew proposed:
>
> 8<
> select setting ~ '--with-libxml' as has_xml
> from pg_config
> where name = 'CONFIGURE';
> has_xml
> - -
> t
> (1 row)
> 8<
>
> In par
On 24 August 2015 at 12:19, Tom Lane wrote:
> David Rowley writes:
> > On 24 August 2015 at 07:31, Tomas Vondra
> > wrote:
> >> 2) in the explain output, there should probably be a space before the
> >> '(inner unique)' text, so
> >>
> >> Hash Join (inner unique) ...
> >>
> >> instead of
> >>
>
David Rowley writes:
> On 24 August 2015 at 07:31, Tomas Vondra
> wrote:
>> 2) in the explain output, there should probably be a space before the
>> '(inner unique)' text, so
>>
>> Hash Join (inner unique) ...
>>
>> instead of
>>
>> Hash Join(inner unique)
>>
>> but that's just nitpicking at
On 08/21/2015 08:34 PM, Jim Nasby wrote:
> On 8/18/15 12:31 PM, Josh Berkus wrote:
>> Also this would be useful for range
>> partitions:
>>
>> CREATE PARTITION ON parent_table USING ( start_value );
>>
>> ... where start_value is the start range of the new partition. Again,
>> easier for users to
On 24 August 2015 at 07:31, Tomas Vondra
wrote:
>
> dim 100k rows, fact 1M rows
> ---
>
> master patched
> --- ---
>
..
> med280.994 261.406 (-7%)
>
>
> dim 1M rows, fact 10M rows
> --
>
> master
On Sun, Aug 23, 2015 at 8:18 PM, Tom Lane wrote:
>
> I've done something about both this and the bipartite_match issue in HEAD.
> I'd be curious to see all the remaining regression differences on VAX.
I'll run a git pull overnight :)
--
greg
--
Sent via pgsql-hackers mailing list (pgsql-hac
xpNitin writes:
> Tried this a few times. I am trying to compile and run PostgreSQL 9.4.0 on
> AIX 7.1.
Is there a particular reason you're trying to build 9.4.0, and not the
current release 9.4.4?
> But DB fails to start. I get this error:
> creating system views ... TRAP: FailedAssertion("!
Hello,
Tried this a few times. I am trying to compile and run PostgreSQL 9.4.0 on
AIX 7.1. I was able to compile with following settings:
CC="xlc_r -q64 -qnoansialias"
CFLAGS="-g -O0"
AR="ar -X64"
OBJECT_MODE=64
./configure --enable-cassert --enable-debug
-with-includes=/opt/freeware/include --wi
Hi,
I did some initial performance evaluation of this patch today, and I see
a clear improvement on larger joins. The scenario I've chosen for the
experiments is a simple fact-dimension join, i.e. a small table
referenced by a large table. So effectively something like this:
CREATE TABLE dim
I wrote:
> On further reflection, there seems little reason not to change it: it's
> pretty silly to imagine that selectivity estimates produced via this
> technique would have anything like 14 decimal places of precision anyhow.
I've done something about both this and the bipartite_match issue in
I wrote:
> Oh, interesting. The largest possible value of "base" is 256, and the
> code limits the amount of string it'll scan to 20 bytes, which means
> "denom" could reach at most 256^21 = 3.7e50. Perfectly fine with
> IEEE-math doubles, but not so much with other arithmetics.
> We could hold
I wrote:
> I think we should replace the whole mess with, say, uint32 for float and
> UINT_MAX for infinity. That will be more portable, probably faster, and
> it will work correctly up to substantially *larger* peak distances than
> the existing code.
After studying the logic a bit more, I reali
Merlin Moncure wrote:
> -* Forget the query stack and constrant-related state information. As
> +* Forget the query stack and constraint-related state information. As
Pushed. Thanks!
--
Kevin Grittner
EDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
--
Sent via
Hi
2015-08-21 7:15 GMT+02:00 Pavel Stehule :
>
>
> 2015-08-20 21:16 GMT+02:00 Jim Nasby :
>
>> On 8/19/15 7:22 PM, Tom Lane wrote:
>>
>>> Jim Nasby writes:
>>>
Don't say "parse names for things other than tables". Only a minority
> of the types of objects used in the database have name
Greg Stark writes:
> On 22 Aug 2015 18:02, "Tom Lane" wrote:
>>> The hang is actually in the groupingset tests in
>>> bipartite_match.c:hk_breadth_search().
>> Is it that function itself that's hanging, or is the problem that its
>> caller expects it to ultimately return true, and it never does?
On 08/23/2015 09:28 AM, Fabien COELHO wrote:
1) fix the docs (explicitly say that it's a Unix epoch)
I would add the word "numeric" in front of timestamp both in the doc and
in the postgresql.conf.sample, as it justifies the chosen %n.
I think we're already using 'unix epoch' in the docs
Hi
2015-08-22 0:09 GMT+02:00 Jim Nasby :
> The following review has been posted through the commitfest application:
> make installcheck-world: tested, passed
> Implements feature: tested, failed
> Spec compliant: not tested
> Documentation:not tested
>
> The feature d
On Sun, Aug 23, 2015 at 10:21 PM, Michael Paquier wrote:
> By the way, perhaps it would be worth doing similar things for the
> other calls of BIO_free and BIO_new, no? I have attached a second
> patch.
And... This second patch had a stupid mistake making for example
ssl_client_dn() fail, so here
On Sat, Aug 22, 2015 at 11:24 PM, Heikki Linnakangas wrote:
> On 07/08/2015 01:15 PM, Дмитрий Воронин wrote:
>>
>> 07.07.2015, 18:34, "Michael Paquier" :
>>
>>> Speaking of which, I have rewritten the patch as attached. This looks
>>> way cleaner than the previous version submitted. Dmitry, do
It is not easy to compare events on a pgbench runs (oops, the tps is down)
with for instance events in postgres log, so as to figure out what may
have cause a given glitch.
This patches adds an option to replace the "time since pgbench run
started" with a timestamp in the progress report so
1) fix the docs (explicitly say that it's a Unix epoch)
I would add the word "numeric" in front of timestamp both in the doc and
in the postgresql.conf.sample, as it justifies the chosen %n.
I think we're already using 'unix epoch' in the docs without explicitly
stating that it's a numeric
Hello Amit,
I have tried your scripts and found some problem while using avg.py
script.
grep 'progress:' test_medium4_FW_off.out | cut -d' ' -f4 | ./avg.py
--limit=10 --length=300
: No such file or directory
I didn't get chance to poke into avg.py script (the command without
avg.py works fin
27 matches
Mail list logo
