Re: select max() much slower than select min()

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

Responses

Browse pgsql-performance by date

  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()