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