Re: Set visibility map bit after HOT prune

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Simon Riggs <simon@2ndQuadrant.com>
Cc: Pavan Deolasee <pavan.deolasee@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2012-12-15T21:48:08Z
Lists: pgsql-hackers
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.

			regards, tom lane