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

From: David Rees <drees76(at)gmail(dot)com>
To: Brian Cox <brian(dot)cox(at)ca(dot)com>
Cc: "Tom Lane [tgl(at)sss(dot)pgh(dot)pa(dot)us]" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner [Kevin(dot)Grittner(at)wicourts(dot)gov]" <Kevin(dot)Grittner(at)wicourts(dot)gov>, "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 20:41:39
Message-ID: 72dbd3150906191341s74629514w12e201740088dfe8@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Fri, Jun 19, 2009 at 1:05 PM, Brian Cox<brian(dot)cox(at)ca(dot)com> wrote:
> Thanks to all for the analysis and suggestions. Since the number of rows in
> an hour < ~500,000, brute force looks to be a fast solution:
>
> select ts_id from ... where ts_interval_start_time >= ... and ...
>
> This query runs very fast as does a single pass through the ids to find the
> min and max.

Along those lines, couldn't you just have the DB do the work?

select max(ts_id), min(ts_id) from ... where ts_interval_start_time >=
... and ...

Then you don't have to transfer 500k ids across the network...

-Dave

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Brian Cox 2009-06-19 21:05:36 Re: select max() much slower than select min()
Previous Message Brian Cox 2009-06-19 20:05:46 Re: select max() much slower than select min()