On Wed, Aug 10, 2005 at 04:24:51PM -0400, Sven Willenberger wrote: > On Wed, 2005-08-10 at 12:58 -0700, Shane wrote: > > On Wed, Aug 10, 2005 at 03:31:27PM -0400, Sven Willenberger wrote: > > > Right off the bat (if I am interpreting the results of your explain > > > analyze correctly) it looks like the planner is basing its decision to > > > seqscan as it thinks that it needs to filter over 1 million rows (versus > > > the 29,000 rows that actually are pulled). Perhaps increasing stats on > > > msgtime and then analyzing the table may help. Depending on your > > > hardware, decreasing random_page_cost in your postgresql.conf just a > > > touch may help too. > > Try increasing stats to 100 on just the msgtime column, not the default > (changing the default will only have an effect on newly created columns > -- you may want to change the default back to 10): Hi, I brought the statistics on msgtime up to 100, vacuum analyzed and brought random_page_cost down to 2. Unfortunately, explain analyze still wants to seqscan and estimates 1m returned rows. Is there a way to simply force an index usage for this particular query? S ---------------------------(end of broadcast)--------------------------- TIP 2: Don't 'kill -9' the postmaster
