Re: Seqscan in MAX(index_column)

From: Andreas Pflug <pgadmin(at)pse-consulting(dot)de>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Greg Stark <gsstark(at)mit(dot)edu>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Seqscan in MAX(index_column)
Date: 2003-09-05 00:16:21
Message-ID: 3F57D5D5.9000509@pse-consulting.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian wrote:

>Greg Stark wrote:
>
>
>>It has nothing to do with MVCC. It has to do with implementing this is hard in
>>the general case.
>>
>>Think of examples like:
>>
>>select max(foo) group by bar;
>>
>>or
>>
>>select max(foo) where xyz = z;
>>
>>To do it properly max/min have to be special-cased and tightly integrated with
>>other code to handle index scans and aggregates. As it currently stands
>>they're implemented the same way as any other aggregate, which means they get
>>to see all the records in the grouping.
>>
>>This is a frequently asked question, I'm surprised you didn't find stuff
>>searching with google. There have been numerous long discussions on this topic
>>not long ago. People are still trying to think about how to handle this
>>better.
>>
>>
>
>The FAQ does have the example of using ORDER BY LIMIT 1 for MAX(). What
>we don't have a workaround for is COUNT(*). I think that will require
>some cached value that obeys MVCC rules of visibility.
>
>
IMHO portability is an important point. People are used to MAX() and
COUNT(*), and will be surprised that they need some special treatment.
While the reasons for this are perfectly explainable, speeding up these
aggregates with some extra effort would make porting a bit easier.

Regards,
Andreas

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2003-09-05 00:36:21 Re: Stats Collector Error 7.4beta1 and 7.4beta2
Previous Message Jan Wieck 2003-09-05 00:03:13 Re: Stats Collector Error 7.4beta1 and 7.4beta2