From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Sean Chittenden <sean(at)chittenden(dot)org> |
Cc: | "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Moving postgresql.conf tunables into 2003... |
Date: | 2003-07-04 01:57:35 |
Message-ID: | 10560.1057283855@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Sean Chittenden <sean(at)chittenden(dot)org> writes:
> Getting the planner to pick
> using the index to filter out data inserted in the last 3 days over
> doing a seq scan... well, I don't know how you could do that without
> changing the random_page_cost.
This sounds a *whole* lot like a correlation issue. If the data in
question were scattered randomly in the table, it's likely that an
indexscan would be a loser. The recently-inserted data is probably
clustered near the end of the table (especially if they're doing VACUUM
FULL after data purges; are they?). But the planner's correlation stats
are much too crude to recognize that situation, if the rest of the table
is not well-ordered.
If their typical process involves a periodic data purge and then a
VACUUM FULL, it might be worth experimenting with doing a CLUSTER on the
timestamp index instead of the VACUUM FULL. The CLUSTER would reclaim
space as effectively as VACUUM FULL + REINDEX, and it would leave the
table with an unmistakable 1.0 correlation ... which should tilt the
planner towards an indexscan without needing a physically impossible
random_page_cost to do it. I think CLUSTER would probably be a little
slower than VACUUM FULL but it's hard to be sure without trying.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2003-07-04 02:38:15 | Re: Moving postgresql.conf tunables into 2003... |
Previous Message | Sean Chittenden | 2003-07-04 00:06:46 | Re: Moving postgresql.conf tunables into 2003... |