On Tue, 2008-04-01 at 10:22 -0400, Tom Lane wrote: > Simon Riggs <simon@xxxxxxxxxxxxxxx> writes: > > On Tue, 2008-04-01 at 13:07 +0530, Pavan Deolasee wrote: > >> Please see the attached patch. One change I made is to hold the SHARE lock > >> on the page while ANALYZE is reading tuples from it. I thought it would > >> be a right thing to do instead of repeatedly acquiring/releasing the lock. > > > ANALYZE is a secondary task and so we shouldn't be speeding it up at the > > possible expense of other primary tasks. So I think holding locks for > > longer than minimum is not good in this case and I see no reason to make > > the change described. > > I think Pavan's change is probably good. In the first place, it's only > a shared buffer lock and besides ANALYZE isn't going to be holding it > long (all it's doing at this point is counting tuples and copying some > of them into memory). In the second place, repeated lock release and > re-grab threatens cache line contention and a context swap storm if > there is anyone else trying to access the page. In the third, whether > there's contention or not the extra acquire/release work will cost CPU > cycles. In the fourth, if we actually believed this was a problem we'd > need to redesign VACUUM too, as it does the same thing. VACUUM waits until nobody else has the buffer pinned, so lock contention is much less of a consideration there. Plus it rearranges the block, which is hard to do one tuple at a time even if we wanted to. -- Simon Riggs 2ndQuadrant http://www.2ndQuadrant.com PostgreSQL UK 2008 Conference: http://www.postgresql.org.uk -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
