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