Re: Performance bug in prepared statement binding in 9.2? - Mailing list pgsql-performance

From Jeff Janes
Subject Re: Performance bug in prepared statement binding in 9.2?
Date
Msg-id CAMkU=1x8qZ4HZ7NmJN=w2vKhxMqyg-eo4awJ26e4jZLFNZsFHw@mail.gmail.com
Whole thread Raw
In response to Re: Performance bug in prepared statement binding in 9.2?  (Josh Berkus <josh@agliodbs.com>)
List pgsql-performance
On Mon, Nov 10, 2014 at 11:04 AM, Josh Berkus <josh@agliodbs.com> wrote:
On 11/10/2014 10:59 AM, Jeff Janes wrote:
> On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus <josh@agliodbs.com> wrote:
>

>> Did this patch every make it in?  Or did it hang waiting for verification?
>>
>
> It made it in:
>
> commit 4162a55c77cbb54acb4ac442ef3565b813b9d07a
> Author: Tom Lane <tgl@sss.pgh.pa.us>
> Date:   Tue Feb 25 16:04:09 2014 -0500

Thanks, then the problem I'm seeing now is something else.

The related problem where the "end" rows are actually needed (e.g. ORDER BY...LIMIT) has not been fixed. 

My idea to fix that was to check if the row's creation-transaction was in the MVCC snapshot (which just uses local memory) before checking if that creation-transaction had committed (which uses shared memory).  But I didn't really have the confidence to push that given the fragility of that part of the code and my lack of experience with it.  See "In progress INSERT wrecks plans on table" thread.

Simon also had some patches to still do the shared memory look up but make them faster by caching where in the list it would be likely to find the match, based on where it found the last match.



Cheers,

Jeff

pgsql-performance by date:

Previous
From: Josh Berkus
Date:
Subject: Lock pileup causes server to stall
Next
From: Alvaro Herrera
Date:
Subject: Re: Lock pileup causes server to stall