On Sat, Jul 25, 2015 at 4:46 AM, Simon Riggs <si...@2ndquadrant.com> wrote: > On 22 July 2015 at 14:59, Robert Haas <robertmh...@gmail.com> wrote: >> Urgh. So if we do this, that forever precludes having HOT pruning set >> the all-visible bit. > > What is the reason why we don't do that already? Surely its a one liner?
I wish! It actually doesn't look simple to me to modify heap_page_prune to know whether any not-all-visible items remain at the end. It's definitely true that, in order for marking the page all-visible to be a possibility, we need to reach heap_page_prune_execute() with ndead == 0. But that's not enough: we also need to know that any tuple that survived the prune operation (that is, it wasn't redirected or marked unused) has a new-enough xmin, which isn't tracked anywhere. vacuumlazy.c solves that problem by making a second pass over all the tuples on the page to determine whether the page is all-visible, but that seems pretty inefficient and I think heap_page_prune() is already a CPU hog on some workloads. (Didn't Heikki have a patch to improve that?) Another sticky wicket is that, as things stand today, we'd have to insert a second WAL record to mark the page all-visible, which would add probably-significant overhead. We could probably modify the format of the record we're already emitting for pruning to carry a flag indicating whether to additionally set PD_ALL_VISIBLE. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
