On Sunday, December 23, 2012 8:11 PM Simon Riggs wrote:
> On 20 December 2012 14:56, Amit Kapila 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 interested in
On 24 December 2012 13:13, Amit Kapila 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 per tuple
>
> 2. Ta
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 tabl
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 h
On 23 December 2012 15:24, Fujii Masao 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 few posts, this s
> 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
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
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 PrintBuff
On 24 December 2012 15:48, Bruce Momjian 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 personall
Greg Smith 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. 1073741824 =
> 0100 0
On 24 December 2012 15:57, Greg Smith 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 find in a Priva
On 24 December 2012 16:07, Tom Lane 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 a visible fail
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 consistent
On Mon, Dec 24, 2012 at 03:57:10PM +, Simon Riggs wrote:
> On 24 December 2012 15:48, Bruce Momjian 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 sug
On 24 December 2012 16:25, Greg Smith 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 assertion 6
Greg Smith 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 the contents of th
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 h
Bruce Momjian 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 above, I thin
On 2012-12-24 18:06:44 +0100, Dimitri Fontaine wrote:
> Bruce Momjian 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
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 w
Josh Berkus 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 a server
On Mon, Dec 24, 2012 at 12:44 AM, Phil Sorber 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
