On Thu, Jan 7, 2010 at 1:43 PM, Brian Cox <brian.cox@xxxxxx> wrote: > On 01/05/2010 08:34 PM, Robert Haas [robertmhaas@xxxxxxxxx] wrote: >> >> - If you have other queries where this index helps (even though it is >> hurting this one), then you're going to have to find a way to execute >> the query without using bound parameters - i.e. with the actual values >> in there instead of $1 through $4. That will allow the planner to see >> that the index scan is a loser because it will see that there are a >> lot of rows in the specified range of ts_interval_start_times. > > I think that this is possible without too much work. Oh, good. > FYI - this test is still running and the same query has been executed at > least 2 more times (it gets done 1-24 times per day) since it took 124M ms > with acceptable response times (several secs). I don't see how either of the > 2 query plans posted could've taken that long (and the actually execution > times I posted confirm this), so I'm assuming that some other plan was used > for the 124M ms execution. Seems like it must have been some NxM plan. Do > you think that autovacuuming more frequently would prevent the query planner > from making this poor choice? That seems pretty speculative... I'm not really sure. ...Robert -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
