Re: select max() much slower than select min() - Mailing list pgsql-performance

From Brian Cox
Subject Re: select max() much slower than select min()
Date
Msg-id 4A3ADE76.9030204@ca.com
Whole thread Raw
In response to select max() much slower than select min()  (Brian Cox <brian.cox@ca.com>)
Responses Re: select max() much slower than select min()
Re: select max() much slower than select min()
List pgsql-performance
Kevin Grittner [Kevin.Grittner@wicourts.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



pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: select max() much slower than select min()
Next
From: "Kevin Grittner"
Date:
Subject: Re: select max() much slower than select min()