From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Brian Cox <brian(dot)cox(at)ca(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: query looping? |
Date: | 2010-01-07 20:16:39 |
Message-ID: | 603c8f071001071216o54ce1fa8v1d8cf68e1186dd86@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Thu, Jan 7, 2010 at 1:43 PM, Brian Cox <brian(dot)cox(at)ca(dot)com> wrote:
> On 01/05/2010 08:34 PM, Robert Haas [robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-01-07 20:19:57 | Re: noob inheritance question |
Previous Message | Dave Crooke | 2010-01-07 20:13:08 | Re: pg_connect takes 3.0 seconds |