On 2012-12-15 16:48:08 -0500, Tom Lane wrote: > Simon Riggs <si...@2ndquadrant.com> writes: > > Doing that only makes sense when we're running a SELECT. Setting the > > all visible bit immediately prior to an UPDATE that clears it again is > > pointless effort, generating extra work for no reason. > > On the other hand, the HOT prune operation itself is worthless when > we're running a SELECT. The only reason we do it that way is that we > have to prune before the query starts to use the page, else pruning > might invalidate pointers-to-tuples that are being held within the > query plan tree. > > Maybe it's time to look at what it'd take for the low-level scan > operations to know whether they're scanning the target relation of > an UPDATE query, so that we could skip pruning altogether except > when a HOT update could conceivably ensue. I think this was discussed > back when HOT went in, but nobody wanted to make the patch more invasive > than it had to be.
FWIW I think that would be a pretty worthwile optimization - I have seen workloads where hot pruning lead to considerable contention. Greetings, Andres Freund -- Andres Freund http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
