Date: Thu, 28 Aug 2003 21:51:09 -0500
From: Bruno Wolff III <bruno@wolff.to>
To: Ken Geis <kgeis@speakeasy.org>
Cc: pgsql-performance@postgresql.org
Subject: Re: bad estimates / non-scanning aggregates
Message-ID: <20030829025109.GD4373@wolff.to>
Mail-Followup-To: Ken Geis <kgeis@speakeasy.org>,
	pgsql-performance@postgresql.org
References: <3F4E99F7.7080604@speakeasy.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <3F4E99F7.7080604@speakeasy.org>
User-Agent: Mutt/1.5.4i

On Thu, Aug 28, 2003 at 17:10:31 -0700,
  Ken Geis <kgeis@speakeasy.org> wrote:
> The query I want to run is
> 
> select stock_id, min(price_date) from day_ends group by stock_id;

The fast way to do this is:

select distinct on (stock_id) stock_id, price_date
  order by stock_id, price_date;

> Also, to get the MIN for a given group, not all values of the index need 
> to be seen.  Must pgsql do a full scan because it treats all aggregates 
> in the same way?  Are MIN and MAX used often enough to justify special 
> treatment, and could that be cleanly implemented?  Perhaps the aggregate 
> function can request the data in a certain order, be told that it is 
> being passed data in a certain order, and return before seeing the 
> entire set of data.

Yes, max and min are not treated special so they don't benefit from
indexes. This has been discussed repeatedly in the archives.