Skip site navigation (1) Skip section navigation (2)

Re: Very specialised query

From: Віталій Тимчишин <tivv00(at)gmail(dot)com>
To: Matthew Wakeling <matthew(at)flymine(dot)org>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Very specialised query
Date: 2009-03-30 18:13:23
Message-ID: 331e40660903301113x7371fb33n302fc3f2c720efb2@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
>
>
> Yeah, that's nice.
>
> However, it is still the case that we can't trust the database to choose
> the correct plan. It is currently only choosing the correct plan now by
> chance, and some time later it may by chance switch to one that takes 40
> minutes.


What is the bad plan? Is it like the first plan from your first message?
You can sometimes tweak optimizer to make sure it will do correct plan. E.g.
when your database fits in memory, you can tweak page access costs. Also
don't forget to raise statistics target.

BTW: About aggregates: they can return arrays, but I can't imagine what you
can group by on... May be windowing functions from 8.4 could help.

Also, if your maximum length (select max(end-start) from location) is low
enough, you can try adding some more constraints to make optimizer happy
(have it more precise row count to select correct plan).

In response to

Responses

pgsql-performance by date

Next:From: Robert HaasDate: 2009-03-30 18:31:39
Subject: Re: Trying to track down weird query stalls
Previous:From: danDate: 2009-03-30 17:50:52
Subject: Trying to track down weird query stalls

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group