From: | mdklatt(at)ou(dot)edu (Michael Klatt) |
---|---|
To: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Perplexing Query Performance |
Date: | 2002-04-15 22:56:26 |
Message-ID: | 2cb75565.0204151456.193bde9@posting.google.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
mdklatt(at)ou(dot)edu (Michael Klatt) wrote in message news:<2cb75565(dot)0204051614(dot)4ad76291(at)posting(dot)google(dot)com>...
> I'm trying to track down a serious performance bottleneck and have
> noticed the following problem. I have a rainfall database with
> approximately 1.2 million records. Different resolutions (daily,
> monthly, etc) are implemented as views, where the main rainfall table
> is aggregated as appropriate. I've been building up a query bit by
> bit to see where it bogs down, and I've found the straw that breaks
> the camel's back.
>
Another update, another problem.
Now the query is bogging down in a new place, and even VACUUM ANALYZE
hasn't fixed it as with my previous problem.
Consider this query:
select *
from daily_rainfall as p, sites as s
where p.site = s.ident and s.latitude >= -90 and s.latitude <= 90 and
s.longitude >= -180 and terrain in ('A', 'I', 'L');
Almost any combination of 'A', 'I', and/or 'L' consistently executes
in the same time, but if it's ONLY 'A' PostgreSQL seems to go off into
Never Never Land. There is no problem if 'I' or 'L' is used alone,
just 'A'.
Does anyone have any ideas?
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2002-04-15 22:57:26 | Re: using CAST and LIKE |
Previous Message | Dmitry Tkach | 2002-04-15 22:10:11 | Re: Alter/update large tables - VERRRY annoying behaviour! |