Robert Haas <robertmh...@gmail.com> writes: > On Sat, Dec 15, 2012 at 4:48 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >> 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.
> I think it's wrong to assume that HOT pruning has no value except in > this case. Truncating dead tuples to line pointers and collapsing HOT > chains speeds up future page scans, and if we were able to set the > all-visible bit, that would help even more. The problem is that this > is all somewhat prospective: HOT pruning the page doesn't help the > *current* scan - in fact, it can sometimes slow it down considerably - > but it can be a great help to the next scan that comes through. Well, no. The problem with the way we do it now is that doing it every time a query scan arrives at a page is too often, resulting in a lot of wasted work. That wasted work is somewhat tolerable as long as it only involves looking at the current page and ending up not actually changing it. If we start generating a lot of useless WAL activity and I/O as a result of thrashing the all-visible bit, it won't be so tolerable anymore. But the problem is not so much the desire to set the bit as that we're doing this whole activity at the wrong place and time. Perhaps doing it every time an UPDATE arrives at the page is too far in the other direction, and we need to look for some other mechanism entirely. I think my core point still stands: the way that HOT pruning is done now is an artifact of having wanted to shoehorn it into the system with minimum changes. Which was reasonable at the time given the experimental status of the feature, but now it's time to reconsider. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers