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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id CAHyXU0yAOx92GH+Zcr6JCNX+2oi4RrqYD=vR_16FOyer7pH6bA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Stephen Frost <sfrost@snowman.net>)
Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Sergey Koposov <koposov@ast.cam.ac.uk>)
Список pgsql-hackers
On Fri, May 25, 2012 at 10:22 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> Hm, what if BufTableHashPartition() was pseudo randomized so that
>> different backends would not get the same buffer partition for a
>> particular tag?
>
> Huh?  You have to make sure that different backends will find the same
> buffer for the same page, so I don't see how that can possibly work.

Right -- duh.  Well, hm.  Is this worth fixing?  ISTM there's a bit of
'optimizing for pgbench-itis' in the buffer partitions -- they seem
optimized to lever the mostly random access behavior of pgbench.  But
how likely is it to see multiple simultaneous scans in the real world?Interleaving scans like that is not a very
effectiveoptimization -- 
if it was me, it'd be trying to organize something around a
partitioned tid scan for parallel sequential access.

merlin


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

Предыдущее
От: Sandro Santilli
Дата:
Сообщение: Re: Interrupting long external library calls
Следующее
От: Stephen Frost
Дата:
Сообщение: Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile