Re: query looping?

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

In response to

Browse pgsql-performance by date

  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