| From: | Hannu Krosing <hannu(at)tm(dot)ee> |
|---|---|
| To: | "Shea,Dan [CIS]" <Dan(dot)Shea(at)ec(dot)gc(dot)ca> |
| Cc: | "'josh(at)agliodbs(dot)com'" <josh(at)agliodbs(dot)com>, "'pgsql-performance(at)postgresql(dot)org'" <pgsql-performance(at)postgresql(dot)org> |
| Subject: | Re: database performance and query performance question |
| Date: | 2004-01-22 23:38:37 |
| Message-ID: | 1074814717.2592.8.camel@fuji.krosing.net |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
Shea,Dan [CIS] kirjutas N, 22.01.2004 kell 23:32:
> The end date in the previous example was actually invalid between
> '2004-01-12'::date and '2003-01-12'::date;
> There have been multiple inserts since I recreated the index but it took
> quite some time to complete the following
> PWFPM_DEV=# explain analyze select * from forecastelement where valid_time
> between '2004-01-12'::date and '2004-01-13'::date;
You could try ORDER BY to bias the optimiser towards using an index:
explain analyze
select *
from forecastelement
where valid_time > '2004-01-12'::date
order by valid_time
limit 10;
This also may be more close to what you are expecting :)
------------------
Hannu
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Greg Stark | 2004-01-23 00:20:25 | Re: database performance and query performance question |
| Previous Message | Josh Berkus | 2004-01-22 21:52:38 | Re: database performance and query performance question |