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

Sean Chittenden <sean@chittenden.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