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

On Fri, May 25, 2012 at 11:38 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Merlin Moncure <mmoncure(at)gmail(dot)com> writes:
>> On Fri, May 25, 2012 at 11:17 AM, Stephen Frost <sfrost(at)snowman(dot)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