Re: Performance bug in prepared statement binding in 9.2?

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: Performance bug in prepared statement binding in 9.2?
Дата
Msg-id CAMkU=1x8qZ4HZ7NmJN=w2vKhxMqyg-eo4awJ26e4jZLFNZsFHw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Performance bug in prepared statement binding in 9.2?  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Josh Berkus
Дата:
Сообщение: Lock pileup causes server to stall
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: Lock pileup causes server to stall