To: gdavis@refractions.net
cc: Chris Browne <cbbrowne@acm.org>, pgsql-performance@postgresql.org
Subject: Re: BUG #2658: Query not using index 
In-reply-to: <4522C8D8.4010601@refractions.net> 
References: <200609272056.k8RKuWjY040283@wwwmaster.postgresql.org>
	<20061003000147.GA31475@wolff.to>
	<4522AA01.4020709@refractions.net>
	<60irj1gr3r.fsf@dba2.int.libertyrms.com>
	<4522B5B9.2050206@refractions.net>
	<60d599gqcz.fsf@dba2.int.libertyrms.com>
	<4522C8D8.4010601@refractions.net>
Comments: In-reply-to Graham Davis <gdavis@refractions.net>
	message dated "Tue, 03 Oct 2006 13:32:24 -0700"
Date: Tue, 03 Oct 2006 16:48:09 -0400
Message-ID: <10941.1159908489@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Graham Davis <gdavis@refractions.net> writes:
> How come an aggreate like that has to use a sequential scan?  I know 
> that PostgreSQL use to have to do a sequential scan for all aggregates, 
> but there was support added to version 8 so that aggregates would take 
> advantage of indexes.

Not in a GROUP BY context, only for the simple case.  Per the comment in
planagg.c:

	 * We don't handle GROUP BY, because our current implementations of
	 * grouping require looking at all the rows anyway, and so there's not
	 * much point in optimizing MIN/MAX.

The problem is that using an index to obtain the maximum value of ts for
a given value of assetid is not the same thing as finding out what all
the distinct values of assetid are.

This could possibly be improved but it would take a considerable amount
more work.  It's definitely not in the category of "bug fix".

			regards, tom lane