Re: [PATCH] Negative Transition Aggregate Functions (WIP)
От | Florian Pflug |
---|---|
Тема | Re: [PATCH] Negative Transition Aggregate Functions (WIP) |
Дата | |
Msg-id | B24844FC-C553-490B-9870-667C752F520E@phlo.org обсуждение исходный текст |
Ответ на | Re: [PATCH] Negative Transition Aggregate Functions (WIP) (David Rowley <dgrowleyml@gmail.com>) |
Список | pgsql-hackers |
On Jan19, 2014, at 20:00 , David Rowley <dgrowleyml@gmail.com> wrote: > I've applied that patch again and put in the sort operators. I've push a new version to https://github.com/fgp/postgres/tree/invtrans This branch includes the following changes * A bunch of missing declaration for *_inv functions * An assert that the frame end doesn't move backwards - I realized thatit is after all easy to do that, if it's done afterthe loop which addsthe new values, not before. * EXPLAIN VERBOSE ANALYZE now shows the max. number of forward aggregatetransitions per row and aggregate. It's a bit imprecise,because it doesn'ttrack the count per aggregate, but it's still a good metric for how wellthe inverse transitionfunctions work. If the number is close to one, youknow that very few rescans are happening. * I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive change, andit's the last commit, so if you object to that,then you can merge up toeafa72330f23f7c970019156fcc26b18dd55be27 instead ofde3d9148be9732c4870b76af96c309eaf1d613d7. A few more things I noticed, all minor stuff * do_numeric_discard()'s inverseTransValid flag is unnecessary. First, if theinverse transition function returns NULL once,we never call it again, so theflag won't have any practical effect. And second, assume we ever called theforward transitionfunction after the inverse fail, and then retried the inverse.In the case of do_numeric_discard(), that actually*could* allow the inverseto suddenly succeed - if the call to the forward function increased the dscalebeyond thatof the element we tried to remove, removal would suddenly bepossible again. We never do that, of course, and it seemsunlikely we everwill. But it's still weird to have code which serves no other purpose than topessimize a case whichwould otherwise just work fine. * The state == NULL checks in all the strict inverse transition functions areredundant. I haven't taken a close look at the documentation yet, I hope to be able to do that tomorrow. Otherwise, things look good as far as I'm concerned. best regards, Florian Pflug
В списке pgsql-hackers по дате отправления: