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

On Jun1, 2012, at 19:51 , Robert Haas wrote:
> On Fri, Jun 1, 2012 at 8:47 AM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> A simpler idea would be to collapse UnpinBuffer() / PinBuffer() pairs
>> by queing UnpinBuffer() requests for a while before actually updating
>> shared state.
>
> So, what happens when somebody wants a cleanup lock on the buffer
> you've decided to keep pinned? We have this problem already; I'm wary
> of making it worse.

She has to wait, or skip the cleanup. We already keep buffers pinned for
potentially a long time - if cursors enter the game even over multiple
commands, I think. And even without cursors, a nestloop plan can keep
buffers used by the outer sub-plan pinned while the inner plan is
executing. So giving the inner plan the chance to do the same seems not
unreasonable.

Plus, the more refined version of that idea from my reply to Tom only
delays the unpinning after the buffer was pinned twice within a short
period of time. After that, it seems to me that the probability of it
getting pinned again is high enough to warrant slightly penalizing a
potential cleanup.

>> 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.

Well, we could drain the queue only if the read() from the socket blocks.
But does pgbench -S really manage to cause significant spinlock contention
due to buffer pinning/unpinning? I'd expect other things to dominate there..

best regards,
Florian Pflug