Re: Sharing aggregate states between different aggregate functions

Поиск
Список
Период
Сортировка
От David Rowley
Тема Re: Sharing aggregate states between different aggregate functions
Дата
Msg-id CAKJS1f-5mFKWi=8i2yuDf7n7Dh+_ChSw-U1f32Go7icnJ=y_uw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Sharing aggregate states between different aggregate functions  (Heikki Linnakangas <hlinnaka@iki.fi>)
Список pgsql-hackers
On 27 July 2015 at 20:11, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
On 07/27/2015 08:34 AM, David Rowley wrote:

In this function I also wasn't quite sure if it was with comparing both
non-NULL INITCOND's here. I believe my code comments may slightly
contradict what the code actually does, as the comments talk about them
having to match, but the code just bails if any are non-NULL. The reason I
didn't check them was because it seems inevitable that some duplicate work
needs to be done when setting up the INITCOND. Perhaps it's worth it?

It would be nice to handle non-NULL initconds. I think you'll have to check that the input function isn't volatile. Or perhaps just call the input function, and check that the resulting Datum is byte-per-byte identical, although that might be awkward to do with the current code structure.


Yeah, it's awkward, as I just managed to remind myself:

The aggtranstype needs to be known before we can call GetAggInitVal() on the initval datum.

That currently happens in build_transstate_for_aggref() only when we've decided to create a new state.

transstate->initValue = GetAggInitVal(textInitVal,
 transstate->aggtranstype);

And to get the aggtranstype:

transstate->aggtranstype =
resolve_aggregate_transtype(aggref->aggfnoid,
aggform->aggtranstype,
inputTypes,
numArguments);

Of course, not impossible, but lots of code gets duplicated.

Regards

David Rowley

--
 David Rowley                   http://www.2ndQuadrant.com/
 PostgreSQL Development, 24x7 Support, Training & Services

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Heikki Linnakangas
Дата:
Сообщение: Re: False comment about speculative insertion
Следующее
От: Kyotaro HORIGUCHI
Дата:
Сообщение: Re: [DESIGN] ParallelAppend