Andreas Brandl <[email protected]> writes:
> we're currently investigating a statistics issue on postgres. We have some
> tables which frequently show up with strange values for n_live_tup. If you
> compare those values with a count on that particular table, there is a
> mismatch of factor 10-30. This causes the planner to come up with very bad
> plans (we also have this issue on bigger table like the one below).
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
--
Sent via pgsql-general mailing list ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general
