| Lists: | pgsql-performance |
|---|
| From: | Brian Herlihy <btherl(at)yahoo(dot)com(dot)au> |
|---|---|
| To: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Query plan issues - volatile tables |
| Date: | 2009-06-04 01:43:06 |
| Message-ID: | 179219.21947.qm@web52310.mail.re2.yahoo.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-performance |
Hi,
We have a problem with some of our query plans. One of our tables is quite volatile, but postgres always uses the last statistics snapshot from the last time it was analyzed for query planning. Is there a way to tell postgres that it should not trust the statistics for this table? Basically we want it to assume that there may be 0, 1 or 100,000 entries coming out from a query on that table at any time, and that it should not make any assumptions.
Thanks,
Brian
========================
Brian Herlihy
Trellian Pty Ltd
+65 67534396 (Office)
+65 92720492 (Handphone)
========================
| From: | Craig James <craig_james(at)emolecules(dot)com> |
|---|---|
| To: | Brian Herlihy <btherl(at)yahoo(dot)com(dot)au> |
| Cc: | Postgresql Performance <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: Query plan issues - volatile tables |
| Date: | 2009-06-04 16:04:12 |
| Message-ID: | 4A27F07C.3050904@emolecules.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Lists: | pgsql-performance |
Brian Herlihy wrote:
> We have a problem with some of our query plans. One of our
>tables is quite volatile, but postgres always uses the last
>statistics snapshot from the last time it was analyzed for query
>planning. Is there a way to tell postgres that it should not
>trust the statistics for this table? Basically we want it to
>assume that there may be 0, 1 or 100,000 entries coming out from
>a query on that table at any time, and that it should not make
>any assumptions.>
I had a similar problem, and just changed my application to do an analyze either just before the query, or just after a major update to the table. Analyze is very fast, almost always a orders of magnitude faster than the time lost to a poor query plan.
Craig