On Tue, Jul 25, 2017 at 07:02:28PM +0200, Tomas Vondra wrote: > On 7/25/17 5:04 PM, Tom Lane wrote: > >Tomas Vondra <tomas.von...@2ndquadrant.com> writes: > >>Attached is a patch that (I think) does just that. The disagreement > >>was caused by VACUUM treating recently dead tuples as live, while > >>ANALYZE treats both of those as dead. > > > >>At first I was worried that this will negatively affect plans in > >>the long-running transaction, as it will get underestimates (due > >>to reltuples not including rows it can see). But that's a problem > >>we already have anyway, you just need to run ANALYZE in the other > >>session. > > > >This definitely will have some impact on plans, at least in cases > >where there's a significant number of unvacuumable dead tuples. So I > >think it's a bit late for v10, and I wouldn't want to back-patch at > >all. Please add to the next commitfest. > > > > I dare to disagree here, for two reasons. > > Firstly, the impact *is* already there, it only takes running ANALYZE. Or > VACUUM ANALYZE. In both those cases we already end up with > reltuples=n_live_tup. > > Secondly, I personally strongly prefer stable predictable behavior over > intermittent oscillations between two values. That's a major PITA on > production, both to investigate and fix.
> FWIW I personally see this as a fairly annoying bug, and would vote to > backpatch it, although I understand people might object. I tend to agree. If you have a setup that somehow never uses ANALYZE or never uses VACUUM on a particular table, you might prefer today's (accidental) behavior. However, the discrepancy arises only on a table that gets dead tuples, and a table that gets dead tuples will see both VACUUM and ANALYZE soon enough. It does seem like quite a stretch to imagine someone wanting plans to depend on which of VACUUM or ANALYZE ran most recently. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers