Re: PoC: Grouped base relation

From: Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: PoC: Grouped base relation
Date: 2017-01-19 07:19:59
Message-ID: 78e8cd48-4a6c-e018-ee79-316d35381286@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 01/19/2017 04:09 AM, Ashutosh Bapat wrote:
> On Thu, Jan 19, 2017 at 12:02 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Tue, Jan 17, 2017 at 11:33 PM, Ashutosh Bapat
>>
>>> Also, the point is naming that kind of function as aggtransmultifn
>>> would mean that it's always supposed to multiply, which isn't true for
>>> all aggregates.
>>
>> TransValue * integer = newTransValue is well-defined for any
>> aggregate. It's the result of aggregating that TransValue with itself
>> a number of times defined by the integer. And that might well be
>> significantly faster than using aggcombinefn many times. On the other
>> hand, how many queries just sit there are re-aggregate the same
>> TransValues over and over again? I am having trouble wrapping my head
>> around that part of this.
>
> Not all aggregates have TransValue * integer = newTransValue
> behaviour. Example is array_agg() or string_agg() has "TransValue
> concatenated integer time" behaviour. Or an aggregate "multiplying"
> values across rows will have TransValue (raised to) integer behaviour.
> Labelling all of those as "multi" doesn't look good.
>

All aggregates that have (or can have) a combine function have it,
because in the worst case you can simply implement it by calling the
combine function repeatedly.

Also, if you treat the combine function as "+" then the "multiply"
function is exactly what "*" is expected to do. So I find the naming
quite appropriate, actually.

But I think naming of the function is not the most important aspect of
the patch, I believe. In the worst case, we can do s/multi/whatever/
sometime later.

regards

--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Haribabu Kommi 2017-01-19 07:25:57 Re: pg_hba_file_settings view patch
Previous Message Ants Aasma 2017-01-19 07:11:02 Re: Causal reads take II