| From: | Gregory Stark <stark(at)enterprisedb(dot)com> |
|---|---|
| To: | "Jeroen T(dot) Vermeulen" <jtv(at)xs4all(dot)nl> |
| Cc: | <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: ANALYZE and index/stats degradation |
| Date: | 2007-07-02 11:15:43 |
| Message-ID: | 877ipj5a5c.fsf@oxford.xeocode.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
"Jeroen T. Vermeulen" <jtv(at)xs4all(dot)nl> writes:
> So I suppose the planner has a good reason to ignore the index at that
> point. I'm assuming that this is something to do with the correlation
> between the index and the column's statistics degrading in some way.
Best to post "explain analyze <query>" for when the performance is good and
bad. Perhaps also an explain analyze for the query with enable_seqscan off
when it's bad.
Also, which version of Postgres is this?
It's possible you just need vacuum to run more frequently on this table and
autovacuum isn't doing it often enough. In which case you might have a cron
job run vacuum (or vacuum analyze) on this table more frequently.
--
Gregory Stark
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jeroen T. Vermeulen | 2007-07-02 13:07:13 | Re: ANALYZE and index/stats degradation |
| Previous Message | Josh Berkus | 2007-07-02 11:05:22 | Re: Postgresql.conf cleanup |