Greg Stark wrote: > From discussions in the bar it sounds like this was actually a false > start however as the RecentGlobalXmin in the backend doing the split > could be less aggressive than the RecentGlobalXmin used by some other > backend to hit the hint bits leading to inconsistent results :(
Yeah, RecentGlobalXmin was wrong, it's not used at the moment. > I'm leaning towards having the backend actually go fetch all the > xmin/xmaxes of the pointers being pruned. It ought to be possible to > skip that check in any database with no live snapshots so recovery > performance would be unaffected on replicas not actively being used in > hot mode. Hmm, I have always been thinking that it would be detrimental to performance to go fetch the xmin/xmaxes, but maybe it indeed wouldn't be so bad if you could optimize the common case where there's no snapshots in the standby. Also, if you have a very busy table where a lot of tuples are killed, many of the heap pages will probably be in cache. -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
