From: | Brian Cox <brian(dot)cox(at)ca(dot)com> |
---|---|
To: | "Kevin Grittner [Kevin(dot)Grittner(at)wicourts(dot)gov]" <Kevin(dot)Grittner(at)wicourts(dot)gov> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: select max() much slower than select min() |
Date: | 2009-06-19 00:40:22 |
Message-ID: | 4A3ADE76.9030204@ca.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Kevin Grittner [Kevin(dot)Grittner(at)wicourts(dot)gov] wrote:
> Is there any correlation between ts_id and ts_interval_start_time?
only vaguely: increasing ts_interval_start_time implies increasing ts_id
but there may be many rows (100,000's) with the same ts_interval_start_time
> Perhaps if you tried min and max with different time ranges it would
> find a row on a backward scan faster. It'll take ten times as long if
> it has to scan through ten times as many rows to find a match.
it looks like there are fewer rows backwards than forwards:
cemdb=> select count(*) from ts_stats_transet_user_interval where
ts_interval_start_time < '2009-6-16 01:00';
count
----------
32100000
(1 row)
cemdb=> select count(*) from ts_stats_transet_user_interval where
ts_interval_start_time >= '2009-6-16 02:00';
count
----------
13500000
(1 row)
> I don't suppose you have an index on ts_interval_start_time?
there is an index. I mentioned this in my orginal posting.
Thanks,
Brian
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2009-06-19 01:10:53 | Re: select max() much slower than select min() |
Previous Message | Kevin Grittner | 2009-06-19 00:15:43 | Re: select max() much slower than select min() |