On Thu, Jan 7, 2010 at 1:43 PM, Brian Cox <brian.cox@ca.com> wrote:
> On 01/05/2010 08:34 PM, Robert Haas [robertmhaas@gmail.com] 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
