| 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: | Whole Thread | Raw Message | 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
| 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 |