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

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: "Brian Cox" <brian(dot)cox(at)ca(dot)com>, "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:15:43
Message-ID: 4A3A925F0200002500027DE0@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Brian Cox <brian(dot)cox(at)ca(dot)com> wrote:

> cemdb=# explain select min(ts_id) from
> ts_stats_transet_user_interval a
> where 0=0 and a.ts_interval_start_time >= '2009-6-16 01:00' and
> a.ts_interval_start_time < '2009-6-16 02:00';

> seems like max() shouldn't take any longer than min() and certainly
> not 10 times as long. Any ideas on how to determine the max more
> quickly?

Is there any correlation between ts_id and 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.

I don't suppose you have an index on ts_interval_start_time?
If not, what happens if you run these queries after adding one?

-Kevin

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Brian Cox 2009-06-19 00:40:22 Re: select max() much slower than select min()
Previous Message Brian Cox 2009-06-18 23:34:39 select max() much slower than select min()