On Jun1, 2012, at 21:07 , Robert Haas wrote: > On Fri, Jun 1, 2012 at 2:54 PM, Florian Pflug <f...@phlo.org> wrote: >> On Jun1, 2012, at 19:51 , Robert Haas wrote: >>> On Fri, Jun 1, 2012 at 8:47 AM, Florian Pflug <f...@phlo.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
