From: | Florian Pflug <fgp(at)phlo(dot)org> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Merlin Moncure <mmoncure(at)gmail(dot)com>, Sergey Koposov <koposov(at)ast(dot)cam(dot)ac(dot)uk>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org, Stephen Frost <sfrost(at)snowman(dot)net> |
Subject: | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Date: | 2012-06-01 19:16:35 |
Message-ID: | 5EC01CE4-BAF3-4B41-A2AA-29826D4725F7@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2012-06-01 20:40:52 | Re: 9.2beta1, parallel queries, ReleasePredicateLocks, CheckForSerializableConflictIn in the oprofile |
Previous Message | Peter Geoghegan | 2012-06-01 19:15:19 | Re: Uh, I change my mind about commit_delay + commit_siblings (sort of) |