Re: Performance bug in prepared statement binding in 9.2?

On Mon, Nov 10, 2014 at 11:04 AM, Josh Berkus <josh(at)agliodbs(dot)com> wrote:

> On 11/10/2014 10:59 AM, Jeff Janes wrote:
> > On Mon, Nov 10, 2014 at 10:48 AM, Josh Berkus <josh(at)agliodbs(dot)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(at)sss(dot)pgh(dot)pa(dot)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