On Mon, Jul 31, 2017 at 1:54 PM, Peter Geoghegan <p...@bowt.ie> wrote: > That is hard to justify. I don't think that failing to set LP_DEAD hints > is the cost that must be paid to realize a benefit elsewhere, though. I > don't see much problem with having both benefits consistently. It's > actually very unlikely that VACUUM will run, and a TID will be recycled > at exactly the wrong time. We could probably come up with a more > discriminating way of detecting that that may have happened, at least > for Postgres 11. We'd continue to use LSN; the slow path would be taken > when the LSN changed, but we do not give up on setting LP_DEAD bits. I > think we can justify going to the heap again in this slow path, if > that's what it takes.
Yeah, that might possibly be a good approach. -- 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
