Re: BUG #2658: Query not using index

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: gdavis(at)refractions(dot)net
Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org
Subject: Re: BUG #2658: Query not using index
Date: 2006-10-03 20:48:09
Message-ID: 10941.1159908489@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs pgsql-performance

Graham Davis <gdavis(at)refractions(dot)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

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Bruno Wolff III 2006-10-03 20:48:11 Re: BUG #2658: Query not using index
Previous Message Bob Friesenhahn 2006-10-03 20:43:18 BUG #2674: libedit not detected

Browse pgsql-performance by date

  From Date Subject
Next Message Bruno Wolff III 2006-10-03 20:48:11 Re: BUG #2658: Query not using index
Previous Message Graham Davis 2006-10-03 20:32:24 Re: BUG #2658: Query not using index