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

From: "Dave Dutcher" <dave(at)tridecap(dot)com>
To: "'Brian Cox'" <brian(dot)cox(at)ca(dot)com>, <pgsql-performance(at)postgresql(dot)org>
Subject: Re: select max() much slower than select min()
Date: 2009-06-19 14:14:37
Message-ID: 61EE390C385F40A599EF08D89A4D2BC5@tridecap.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> -----Original Message-----
> From: Brian Cox
> Subject: [PERFORM] select max() much slower than select min()
>

> 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?

That is odd. It seems like max should actually have to scan fewer rows than
min should. It might still be bloat in the table, because unless you did
VACUUM FULL there could still be dead rows. A vacuum verbose would show if
there is bloat or not. Also maybe you could try a two column index like
this:

create index test_index on ts_stats_transet_user_interval
(ts_interval_start_time, ts_id);

Dave

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-06-19 14:26:15 Re: select max() much slower than select min()
Previous Message Kenneth Marshall 2009-06-19 13:33:49 Re: 8.4 COPY performance regression on Solaris