Re: [HACKERS] Improving avg performance for numeric

2013-03-15 Thread Pavel Stehule
Hello 2013/3/16 Hadi Moshayedi : > Revisiting: > http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz > > I think the reasons which the numeric average was slow were: > (1) Using Numeric for count, which is slower than int8 to increment, > (2) Constructing/deconstructing array

[HACKERS] Improving avg performance for numeric

2013-03-15 Thread Hadi Moshayedi
Revisiting: http://www.postgresql.org/message-id/45661be7.4050...@paradise.net.nz I think the reasons which the numeric average was slow were: (1) Using Numeric for count, which is slower than int8 to increment, (2) Constructing/deconstructing arrays at each transition step. This is also disc

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Alvaro Herrera
Tom Lane wrote: > [ wanders away wondering why IntoClause has grown a relkind field... ] See transformCreateTableAsStmt, SetupForCreateTableAs, intorel_startup. gram.y uses the convention of assigning '\0' to it initially and parse analysis fills in the right value. I wonder if a boolean field w

Re: [HACKERS] Should array_length() Return NULL

2013-03-15 Thread David E. Wheeler
On Mar 15, 2013, at 3:42 PM, Tom Lane wrote: >> Oh. Is there a way to declare an empty 1-dimension array? > > Doesn't look like it: > > regression=# select '[1:0]={}'::text[]; > ERROR: upper bound cannot be less than lower bound > LINE 1: select '[1:0]={}'::text[]; > ^ > > Possi

Re: [HACKERS] in-catalog Extension Scripts and Control parameters (templates?)

2013-03-15 Thread Dimitri Fontaine
Tom Lane writes: > Um ... what's with those hstore changes? Just showing how we could deal with shipping 1.1 in the future, it's not meant to be applied as-is. Part of the feature set in there comes from when Robert complained that we can't have CREATE EXTENSION hstore; install version 1.1 fr

Re: [HACKERS] Should array_length() Return NULL

2013-03-15 Thread Tom Lane
"David E. Wheeler" writes: > Oh. Is there a way to declare an empty 1-dimension array? Doesn't look like it: regression=# select '[1:0]={}'::text[]; ERROR: upper bound cannot be less than lower bound LINE 1: select '[1:0]={}'::text[]; ^ Possibly we should allow that, but just as

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Tom Lane
Kevin Grittner writes: > Kevin Grittner wrote: > The presence of default_with_oids and the special-handling of the > oids option via interpretOidsOption() makes it hard to come up with > a solution which would qualify as "elegant".  Here's a rough cut at > an approach which seems best to me.  If

Re: [HACKERS] Should array_length() Return NULL

2013-03-15 Thread David E. Wheeler
On Mar 15, 2013, at 3:07 PM, Tom Lane wrote: > The thing is that that syntax creates an array of zero dimensions, > not one that has 1 dimension and zero elements. So "0" would be > incorrect. > > Our handling of empty arrays leaves something to be desired, I agree, > but making it more consist

Re: [HACKERS] Should array_length() Return NULL

2013-03-15 Thread Tom Lane
"David E. Wheeler" writes: > This surprised me: > david=# select array_length('{}'::text[], 1); > array_length > -- >[null] > I had expecte dit to retur 0. I might expect NULL for a NULL param, but not > one that's defined but has no elements. The thing is

Re: [HACKERS] in-catalog Extension Scripts and Control parameters (templates?)

2013-03-15 Thread Tom Lane
Alvaro Herrera writes: > Here's a rebased version; there were some merge conflicts with master. Um ... what's with those hstore changes? regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http:/

[HACKERS] Should array_length() Return NULL

2013-03-15 Thread David E. Wheeler
Hackers, This surprised me: david=# select array_length('{}'::text[], 1); array_length -- [null] I had expecte dit to retur 0. I might expect NULL for a NULL param, but not one that's defined but has no elements. Best, David -- Sent via pgsql-hackers mai

Re: [HACKERS] Re: Doc patch making firm recommendation for setting the value of commit_delay

2013-03-15 Thread Tom Lane
Noah Misch writes: > I'm marking this patch Ready for Committer, qualified with a recommendation to > adopt only the wal.sgml changes. I've committed this along with some further wordsmithing. I kept Peter's change to pg_test_fsync's default -s value; I've always felt that 2 seconds was laughabl

Re: [HACKERS] pg_test_fsync crashes on systems with POSIX signal handling

2013-03-15 Thread Bruce Momjian
On Fri, Mar 15, 2013 at 03:05:54PM -0400, Tom Lane wrote: > On my old HPUX box: > > $ ./pg_test_fsync > 2 seconds per test > Direct I/O is not supported on this platform. > > Compare file sync methods using one 8kB write: > (in wal_sync_method preference order, except fdatasync > is Linux's defau

Re: [HACKERS] Add some regression tests for SEQUENCE

2013-03-15 Thread robins
Hi, I've added some regression tests for SEQUENCE. A cumulative patch is attached. Barring a (still to decipher) function seq_redo() and trying to learn how to actually test it, this takes care of most branches of ( src/backend/commands/sequence.c) taking code-coverage (of 'make check') to ~95%.

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Kevin Grittner
Kevin Grittner wrote: > Tom Lane wrote: >> Kevin Grittner writes: >>> I failed to touch everything necessary to prevent MVs from >>> having OIDs.  This patch fixes the reported problem, and >>> doesn't leave any gaps as far as I know; but I will do >>> additional review to try to catch any other

[HACKERS] pg_test_fsync crashes on systems with POSIX signal handling

2013-03-15 Thread Tom Lane
On my old HPUX box: $ ./pg_test_fsync 2 seconds per test Direct I/O is not supported on this platform. Compare file sync methods using one 8kB write: (in wal_sync_method preference order, except fdatasync is Linux's default) open_datasync 165.122 ops/sec ( 6056 micros

Re: [HACKERS] Strange Windows problem, lock_timeout test request

2013-03-15 Thread Tom Lane
Boszormenyi Zoltan writes: > [ 2-lock_timeout-v33.patch ] I looked at this patch a bit. I don't understand why you've chosen to alter the API of the enable_timeout variants to have a bool result that says "I didn't bother to process the timeout because it would have fired immediately". That is

Re: [HACKERS] buffer assertion tripping under repeat pgbench load

2013-03-15 Thread Tom Lane
Greg Smith writes: > On 1/27/13 2:32 AM, Satoshi Nagayasu wrote: >> This patch is intended to improve warning message at >> AtEOXact_Buffers(), but I guess another function, >> AtProcExit_Buffers(), needs to be modified as well. Right? > Yes, good catch. I've attached an updated patch that does

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Kevin Grittner
Tom Lane wrote: > Kevin Grittner writes: >> I failed to touch everything necessary to prevent MVs from >> having OIDs.  This patch fixes the reported problem, and doesn't >> leave any gaps as far as I know; but I will do additional review >> to try to catch any other omissions.  I figured I shoul

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Tom Lane
Kevin Grittner writes: > I failed to touch everything necessary to prevent MVs from having > OIDs.  This patch fixes the reported problem, and doesn't leave any > gaps as far as I know; but I will do additional review to try to > catch any other omissions.  I figured I should address the reported

Re: [HACKERS] Materialized view assertion failure in HEAD

2013-03-15 Thread Kevin Grittner
Joachim Wieland wrote: > I'm getting an assertion failure in HEAD with materialized views > To reproduce, just run make installcheck, dump the regression > database and then restore it, the server crashes during restore. I failed to touch everything necessary to prevent MVs from having OIDs.  T

Re: [HACKERS] [v9.3] writable foreign tables

2013-03-15 Thread Tom Lane
Robert Haas writes: > On Mon, Mar 11, 2013 at 3:06 PM, Tom Lane wrote: >> Greg Stark writes: >>> It feels a bit like unpredictable magic to have "DEFAULT" mean one >>> thing and omitted columns mean something else. >> Agreed. The current code behaves that way, but I think that's >> indisputabl

Re: [HACKERS] lock AccessShareLock on object 0/1260/0 is already held

2013-03-15 Thread Pavel Stehule
Hello 2013/1/4 Pavel Stehule : > 2013/1/4 Tom Lane : >> Pavel Stehule writes: >>> What is state of this issue? >>> http://archives.postgresql.org/pgsql-hackers/2011-09/msg00423.php >> >> AFAICS we never identified the cause. It was pretty clear that >> something was failing to clean up shared-me

Re: [HACKERS] Enabling Checksums

2013-03-15 Thread Andres Freund
On 2013-03-15 14:32:57 +0200, Ants Aasma wrote: > On Wed, Mar 6, 2013 at 1:34 PM, Heikki Linnakangas > wrote: > > Fletcher's checksum is good in general, I was mainly worried about > > truncating the Fletcher-64 into two 8-bit values. I can't spot any obvious > > weakness in it, but if it's indeed

Re: [HACKERS] Enabling Checksums

2013-03-15 Thread Ants Aasma
On Fri, Mar 15, 2013 at 2:32 PM, Ants Aasma wrote: > I was able to coax GCC to vectorize the code in the attached patch Now actually attached. Ants Aasma -- Cybertec Schönig & Schönig GmbH Gröhrmühlgasse 26 A-2700 Wiener Neustadt Web: http://www.postgresql-support.de parallel-checksum.patch D

Re: [HACKERS] Enabling Checksums

2013-03-15 Thread Ants Aasma
On Wed, Mar 6, 2013 at 1:34 PM, Heikki Linnakangas wrote: > Fletcher's checksum is good in general, I was mainly worried about > truncating the Fletcher-64 into two 8-bit values. I can't spot any obvious > weakness in it, but if it's indeed faster and as good as a straightforward > Fletcher-16, I

Re: [HACKERS] Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

2013-03-15 Thread Boszormenyi Zoltan
2013-03-15 00:48 keltezéssel, Boszormenyi Zoltan írta: 2013-03-13 21:28 keltezéssel, Boszormenyi Zoltan írta: 2013-03-13 13:45 keltezéssel, Andres Freund írta: On 2013-03-13 09:09:24 +0100, Boszormenyi Zoltan wrote: 2013-03-13 07:42 keltezéssel, Craig Ringer írta: On 03/12/2013 06:27 AM, Crai