Re: [PATCH] Negative Transition Aggregate Functions (WIP)

Поиск
Список
Период
Сортировка
От Florian Pflug
Тема Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Дата
Msg-id 6A63E8E8-949B-4EF6-8F81-029CB22FF370@phlo.org
обсуждение исходный текст
Ответ на Re: [PATCH] Negative Transition Aggregate Functions (WIP)  (David Rowley <dgrowleyml@gmail.com>)
Ответы 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
which includes

* A bunch of missing declaration for *_inv functions

* An assert that the frame end doesn't move backwards - I realized that it is after all easy to do that, if it's done
afterthe loop which adds the new values, not before. 

* EXPLAIN VERBOSE ANALYZE now shows the max. number of forward aggregate transitions per row and aggregate. It's a bit
imprecise,because it doesn't track the count per aggregate, but it's still a good metric for how well the inverse
transitionfunctions work. If the number is close to one, you know that very few rescans are happening. 

* I've also renamed INVFUNC to INVSFUNC. That's a pretty invasive change, and it's the last commit, so if you object to
that,then you can merge up to eafa72330f23f7c970019156fcc26b18dd55be27 instead of
de3d9148be9732c4870b76af96c309eaf1d613d7.

A few more things I noticed, all minor stuff

* do_numeric_discard()'s inverseTransValid flag is unnecessary. First, if the inverse transition function returns NULL
once,we never call it again, so the flag won't have any practical effect. And second, assume we ever called the forward
transitionfunction after the inverse fail, and then retried the inverse. In the case of do_numeric_discard(), that
actually*could* allow the inverse to suddenly succeed - if the call to the forward function increased the dscale beyond
thatof the element we tried to remove, removal would suddenly be possible again. We never do that, of course, and it
seemsunlikely we ever will. But it's still weird to have code which serves no other purpose than to pessimize a case
whichwould otherwise just work fine. 

* The state == NULL checks in all the strict inverse transition functions are redundant.

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 по дате отправления:

Предыдущее
От: Dave Chinner
Дата:
Сообщение: Re: [Lsf-pc] Linux kernel impact on PostgreSQL performance
Следующее
От: Rami Grossman
Дата:
Сообщение: Hstore 2.0 patch