Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support
От | Pavel Stehule |
---|---|
Тема | Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support |
Дата | |
Msg-id | 162867790912201321v50da73c4ta169aedd62970b7f@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Proposal: Pre ordered aggregates, default ORDER BY clause for aggregates - median support (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Proposal: Pre ordered aggregates, default ORDER BY
clause for aggregates - median support
|
Список | pgsql-hackers |
2009/12/20 Tom Lane <tgl@sss.pgh.pa.us>: > Pavel Stehule <pavel.stehule@gmail.com> writes: >> I am thinking about implementation of median function. This function >> should be implemented in two ways: > >> a) direct entering an ORDER BY clause for median funcall in gram.y >> b) general support for "preordered aggregates". > >> I prefer plan b, because there are more similar aggregates - like >> Quantiles. > > This seems like a great deal of mechanism to solve a very localized > problem. > plan a doesn't block plan b - it is very simple. So we can start with a. > I think that we've already expanded the capabilities of aggregates > a great deal for 8.5, and we should let it sit as-is for a release > or two and see what the real user demand is for additional features. > > I'm particularly concerned by the fact that the feature set is already > far out in front of what the planner can optimize effectively (e.g., > there's no ability to combine the work when multiple aggregates need the > same sorted data). The more features we add on speculation, the harder > it's going to be to close that gap. I didn't thing about this optimalisation, but this point could not be impossible. Bigger problem is using of indexes. > > Another risk is that features added now might preclude adding others > later. > sure. It was my question, what is preferred. Regards Pavel > regards, tom lane >
В списке pgsql-hackers по дате отправления: