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

Поиск
Список
Период
Сортировка
От Merlin Moncure
Тема Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile
Дата
Msg-id CAHyXU0wkHN3_0gB2EveLKMeuoXCDDvU95t5mx=wCEk9nUGK4Cg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Fri, May 25, 2012 at 11:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Fri, May 25, 2012 at 11:17 AM, Stephen Frost <sfrost@snowman.net> wrote:
>>> Didn't we implement a system whereby this is exactly what we intend to
>>> happen on the read side- that is, everyone doing a SeqScan gangs up on
>>> one ring buffer and follows it, which we felt was going to dramatically
>>> improve performance in some cases?
>
>> yeah:
>> ...
>> I wonder if the logic here is just being too strict...
>
> I don't recall how much evidence there is behind the NBuffers/4 threshold.
> Maybe that needs some tuning?


probably.  Sergey is going to get some numbers back from a hacked
version that forces the scan to use a strategy.

If that turns out to be the problem, I bet it'd make sense to hook the
decision against ring size which is currently internal to freelist.
In other words, since freelist is making the call to determine the
size of the ring, it should also probably be making the call in terms
of a particular input size being useful to apply a strategy to.

Maybe something like
IsAccessStrategyUseful(BufferAccessStrategyType btype, BlockNumber nblocks) ...

merlin


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

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: incorrect handling of the timeout in pg_receivexlog
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: Re: [BUGS] 9.2beta1 regression: pg_restore --data-only does not set sequence values any more