Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search for
  Advanced Search

Re: BUG #2658: Query not using index


  • From: Graham Davis <gdavis(at)refractions(dot)net>
  • To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
  • Cc: Chris Browne <cbbrowne(at)acm(dot)org>, pgsql-performance(at)postgresql(dot)org
  • Subject: Re: BUG #2658: Query not using index
  • Date: Tue, 03 Oct 2006 13:52:28 -0700
  • Message-id: <4522CD8C(dot)1000108(at)refractions(dot)net>

Thanks Tom, that explains it and makes sense. I guess I will have to accept this query taking 40 seconds, unless I can figure out another way to write it so it can use indexes. If there are any more syntax suggestions, please pass them on. Thanks for the help everyone.

Graham.


Tom Lane wrote:

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


--
Graham Davis
Refractions Research Inc.
gdavis(at)refractions(dot)net




Home | Main Index | Thread Index

Privacy Policy | PostgreSQL Archives hosted by Command Prompt, Inc. | Designed by tinysofa
Copyright © 1996 – 2008 PostgreSQL Global Development Group