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

On Jun1, 2012, at 21:07 , Robert Haas wrote:
> On Fri, Jun 1, 2012 at 2:54 PM, Florian Pflug <fgp(at)phlo(dot)org> wrote:
>> 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:
>>>> 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.
>
> I believe that it's going to block frequently on this type of
> workload. pgbench isn't fast enough to get the next query over there
> by the time postgres is ready for the next query.
>
>> But does pgbench -S really manage to cause significant spinlock contention
>> due to buffer pinning/unpinning? I'd expect other things to dominate there..
>
> See previous note. It may not be the biggest effect, but I think it's
> in the mix.

Ok, now you've lost me. If the read() blocks, how on earth can a few
additional pins/unpins ever account for any meaningful execution time?

It seems to me that once read() blocks we're talking about a delay in the
order of the scheduling granularity (i.e., milliseconds, in the best case),
while even in the word case pinning a buffer shouldn't take more than
1000 cycles (for comparison, I think a cache miss across all layers costs
a few hundred cycles). So there's at the very least 3 order of magnitude
between those two...

best regards,
Florian Pflug