Andreas Brandl <ml@xxxxxxxxxxxxxx> 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 (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
