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.
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?
Brian
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
