Re: After VACUUM, statistics become skewed
От | Tom Lane |
---|---|
Тема | Re: After VACUUM, statistics become skewed |
Дата | |
Msg-id | 7858.1053535866@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | After VACUUM, statistics become skewed (Robert.Farrugia@go.com.mt) |
Список | pgsql-admin |
Robert.Farrugia@go.com.mt writes: > Given a table around 4GB in size containing millions of records, before > vacuuming the following query used the correct index > (mo_200302_called_idx) which is built on answertime and callednumber_type. Could we see EXPLAIN ANALYZE results for both the good plan and the bad plan, for the same query? You're not giving us comparable results. It would also be useful to show the pg_stats entries for the table. I suspect that the planner is being fooled by some odd statistics of your data, but we have not got any info here with which to speculate. > Usually by dropping the table and reloading it from > disk may solve the problem (it may take more than one try), but this is > becoming unpractical due to the amount of data to restore each time. You can get back to the un-analyzed state by deleting the rows in pg_statistic for this table, viz delete from pg_statistic where starelid = (select oid from pg_class where relname = 'mobileorig_200302'); Grotty, but it sure beats dropping and reloading a big table. regards, tom lane
В списке pgsql-admin по дате отправления: