Re: Seqscan in MAX(index_column)
От | Andreas Pflug |
---|---|
Тема | Re: Seqscan in MAX(index_column) |
Дата | |
Msg-id | 3F57D5D5.9000509@pse-consulting.de обсуждение исходный текст |
Ответ на | Re: Seqscan in MAX(index_column) (Bruce Momjian <pgman@candle.pha.pa.us>) |
Список | 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
В списке pgsql-hackers по дате отправления: