Re: BUG #2658: Query not using index

От: Tom Lane
Тема: Re: BUG #2658: Query not using index
Дата: ,
Msg-id: 10941.1159908489@sss.pgh.pa.us
(см: обсуждение, исходный текст)
Ответ на: Re: BUG #2658: Query not using index  (Graham Davis)
Ответы: Re: BUG #2658: Query not using index  (Graham Davis)
Список: pgsql-performance

Скрыть дерево обсуждения

Re: BUG #2658: Query not using index  (Graham Davis, )
 Re: BUG #2658: Query not using index  (Chris Browne, )
  Re: BUG #2658: Query not using index  (Graham Davis, )
  Re: BUG #2658: Query not using index  (Graham Davis, )
   Re: BUG #2658: Query not using index  (Bruno Wolff III, )
 Re: BUG #2658: Query not using index  (Chris Browne, )
  Re: BUG #2658: Query not using index  (Graham Davis, )
   Re: BUG #2658: Query not using index  (Tom Lane, )
    Re: BUG #2658: Query not using index  (Graham Davis, )
     Re: BUG #2658: Query not using index  (Mark Lewis, )
      Re: BUG #2658: Query not using index  (Graham Davis, )
       Re: BUG #2658: Query not using index  (Mark Lewis, )
        Re: BUG #2658: Query not using index  (Graham Davis, )
         Re: BUG #2658: Query not using index  (Mark Lewis, )
          Re: BUG #2658: Query not using index  (Tom Lane, )
 PostgreSQL Caching  ("Adnan DURSUN", )
  Re: PostgreSQL Caching  ("Tomeh, Husam", )
   Re: PostgreSQL Caching  ("Adnan DURSUN", )
    Re: PostgreSQL Caching  ("Tomeh, Husam", )
     Re: PostgreSQL Caching  ("Adnan DURSUN", )
      Re: PostgreSQL Caching  ("Dave Dutcher", )
       Re: PostgreSQL Caching  (Brad Nicholson, )
     Re: PostgreSQL Caching  (Brad Nicholson, )

Graham Davis <> 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


В списке pgsql-performance по дате сообщения:

От: "Adnan DURSUN"
Дата:
Сообщение: Re: PostgreSQL Caching
От: "simon godden"
Дата:
Сообщение: simple case using index on windows but not on linux