Re: Set visibility map bit after HOT prune

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Simon Riggs <simon(at)2ndQuadrant(dot)com>
Cc: Pavan Deolasee <pavan(dot)deolasee(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Set visibility map bit after HOT prune
Date: 2012-12-15 21:48:08
Message-ID: 29275.1355608088@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Simon Riggs <simon(at)2ndQuadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2012-12-15 22:06:07 Re: LATERAL and VOLATILE functions
Previous Message Pavel Stehule 2012-12-15 21:47:48 LATERAL and VOLATILE functions