On Sunday, December 23, 2012 8:11 PM Simon Riggs wrote:
On 20 December 2012 14:56, Amit Kapila amit.kap...@huawei.com wrote:
1. There is no performance change for cloumns that have all valid
values(non- NULLs).
I don't see any tests (at all) that measure this.
I'm particularly
On 24 December 2012 13:13, Amit Kapila amit.kap...@huawei.com wrote:
Apart from above, the performance data for less number of columns (where the
trailing nulls are such that they cross word boundary) also show similar
gains:
The below cases (2 3) can give benefit as it will save 4 bytes
Simon Riggs wrote:
Not really sure about the 100s of columns use case.
But showing gain in useful places in these more common cases wins
my vote.
Thanks for testing. Barring objections, will commit.
Do we have any results on just a plain, old stock pgbench run, with
the default table
On Monday, December 24, 2012 7:58 PM Kevin Grittner wrote:
Simon Riggs wrote:
Not really sure about the 100s of columns use case.
But showing gain in useful places in these more common cases wins
my vote.
Thanks for testing. Barring objections, will commit.
Do we have any results
On 23 December 2012 15:24, Fujii Masao masao.fu...@gmail.com wrote:
The latest patch is the following. Of course, this cannot be applied
cleanly in HEAD.
http://archives.postgresql.org/message-id/CAHGQGwHB==cjehme6jiuy-knutrx-k3ywqzieg1gpnb3ck6...@mail.gmail.com
Just by looking at the last
From: charle...@outlook.com
To: cbbro...@gmail.com
CC: pgsql-hackers@postgresql.org
Subject: Re: [HACKERS] Writing Trigger Functions in C
Date: Fri, 21 Dec 2012 12:27:26 -0500
Date: Fri, 21 Dec 2012 11:56:25 -0500
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
I don't think that represents enough change to keep people happy, but
I don't see anything else useful being suggested in this patch. Other
design thoughts welcome, but personally, I think rushing this design
through at this stage is
On 12/23/12 3:17 PM, Simon Riggs wrote:
We already have PrintBufferLeakWarning() for this, which might be a bit neater.
Maybe. I tried using this, and I just got a seg fault within that code.
I can't figure out if I called it incorrectly or if the buffer
involved is so damaged that
On 24 December 2012 15:48, Bruce Momjian br...@momjian.us wrote:
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
I don't think that represents enough change to keep people happy, but
I don't see anything else useful being suggested in this patch. Other
design thoughts welcome, but
Greg Smith g...@2ndquadrant.com writes:
I did get some output from the variation Andres suggested. There was
exactly one screwed up buffer:
2012-12-24 06:08:46 EST [26015]: WARNING: refcount of base/16384/49169
is 1073741824 should be 0, globally: 0
That is pgbench_accounts_pkey.
On 24 December 2012 15:57, Greg Smith g...@2ndquadrant.com wrote:
2012-12-24 06:08:46 EST [26015]: WARNING: refcount of base/16384/49169 is
1073741824 should be 0, globally: 0
That is pgbench_accounts_pkey. 1073741824 =
0100 = 2^30
Pretty odd value to
On 24 December 2012 16:07, Tom Lane t...@sss.pgh.pa.us wrote:
Huh. Looks a bit like overflow of the refcount, which would explain why
it takes such a long test case to reproduce it. But how could that be
happening without somebody forgetting to decrement the refcount, which
ought to lead to
On 12/24/12 11:10 AM, Simon Riggs wrote:
I wonder if you're having a hardware problem?
Always possible. I didn't report this until I had replicated the crash
and seen exactly the same thing twice. I've seen it crash on this
assertion 6 times now. Bad hardware is not normally so
On Mon, Dec 24, 2012 at 03:57:10PM +, Simon Riggs wrote:
On 24 December 2012 15:48, Bruce Momjian br...@momjian.us wrote:
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
I don't think that represents enough change to keep people happy, but
I don't see anything else useful
On 24 December 2012 16:25, Greg Smith g...@2ndquadrant.com wrote:
On 12/24/12 11:10 AM, Simon Riggs wrote:
I wonder if you're having a hardware problem?
Always possible. I didn't report this until I had replicated the crash and
seen exactly the same thing twice. I've seen it crash on this
Greg Smith g...@2ndquadrant.com writes:
I kicked off another test that includes the block number just before Tom
suggested it, so I should have the block by tomorrow at the latest. The
range of runtime before crash is 3 to 14 hours so far.
Cool. Once you get the crash, please also capture
On Monday, December 24, 2012 7:58 PM Kevin Grittner wrote:
Simon Riggs wrote:
Not really sure about the 100s of columns use case.
But showing gain in useful places in these more common cases wins
my vote.
Thanks for testing. Barring objections, will commit.
Do we have any results
Bruce Momjian br...@momjian.us writes:
Is that what everyone else wants? If that is all, let's do it and close
the item.
What Simon is proposing is quite clear and not what you pasted, if I'm
reading that correctly:
On Mon, Dec 24, 2012 at 03:13:59PM +, Simon Riggs wrote:
From all of the
On 2012-12-24 18:06:44 +0100, Dimitri Fontaine wrote:
Bruce Momjian br...@momjian.us writes:
Is that what everyone else wants? If that is all, let's do it and close
the item.
What Simon is proposing is quite clear and not what you pasted, if I'm
reading that correctly:
On Mon, Dec 24,
Simon,
What the patch doesn't change is the requirement to have a file that
causes the server to place itself into archive recovery. So there is
no more recovery.conf and instead we have a file called
recovery.trigger instead.
Requiring a file in order to make a server a replica is what we
Josh Berkus j...@agliodbs.com writes:
What the patch doesn't change is the requirement to have a file that
causes the server to place itself into archive recovery. So there is
no more recovery.conf and instead we have a file called
recovery.trigger instead.
Requiring a file in order to make
On Mon, Dec 24, 2012 at 12:44 AM, Phil Sorber p...@omniti.com wrote:
Updated patch attached.
Thanks. I am marking this patch as ready for committer.
--
Michael Paquier
http://michael.otacoo.com
22 matches
Mail list logo
