Re: query looping?

From: Brian Cox <brian(dot)cox(at)ca(dot)com>
To: "Robert Haas [robertmhaas(at)gmail(dot)com]" <robertmhaas(at)gmail(dot)com>
Cc: "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: query looping?
Date: 2010-01-07 18:43:25
Message-ID: 4B462B4D.5020203@ca.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

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.

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

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Nikolas Everett 2010-01-07 18:52:40 Re: Joining on text field VS int
Previous Message Nikolas Everett 2010-01-07 18:11:15 Re: Air-traffic benchmark