Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile

Поиск
Список
Период
Сортировка
От Jeff Janes
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id CAMkU=1yqT4LK6dDa+Ta=8PxJvTxp_=nqsAa+4pPCT5xzufoUUw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Fri, Jun 1, 2012 at 10:51 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 1, 2012 at 8:47 AM, Florian Pflug <fgp@phlo.org> wrote:
>
>> We'd drain the unpin queue whenever we don't expect a PinBuffer() request
>> to happen for a while. Returning to the main loop is an obvious such place,
>> but there might be others.
>
> However, on a workload like pgbench -S, dropping the pin when you
> return to the main loop would render the optimization useless.

But do we need the optimization on a workload like pgbench -S?  You
did some pretty massive scalability tests on that front, and I don't
think this problem was identified in them.

Cheers,

Jeff


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: [RFC] Interface of Row Level Security
Следующее
От: Florian Pflug
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile