Re: Set visibility map bit after HOT prune

On 2012-12-15 16:48:08 -0500, Tom Lane wrote:
> Simon Riggs <simon@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