Re: Moving postgresql.conf tunables into 2003...

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