Andreas Brandl <ml@3.141592654.de> writes:
> we're currently investigating a statistics issue on postgres. We have some tables which frequently show up with
strangevalues for n_live_tup. If you compare those values with a count on that particular table, there is a mismatch of
factor10-30. This causes the planner to come up with very bad plans (we also have this issue on bigger table like the
onebelow).
The planner doesn't use n_live_tup; the only thing that that's used for
is decisions about when to autovacuum/autoanalyze. So you have two
problems here not one.
Can you provide a test case for the n_live_tup drift? That is,
something that when done over and over causes n_live_tup to get further
and further from reality?
regards, tom lane
