Re: Partial aggregates pushdown

From: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
To: "Fujii(dot)Yuki(at)df(dot)MitsubishiElectric(dot)co(dot)jp" <Fujii(dot)Yuki(at)df(dot)mitsubishielectric(dot)co(dot)jp>
Cc: Bruce Momjian <bruce(at)momjian(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, Julien Rouhaud <rjuju123(at)gmail(dot)com>, Daniel Gustafsson <daniel(at)yesql(dot)se>, Ilya Gladyshev <i(dot)gladyshev(at)postgrespro(dot)ru>
Subject: Re: Partial aggregates pushdown
Date: 2023-06-08 07:39:30
Message-ID: 0a3960c36e705dccfce667f04f0bf632@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Fujii(dot)Yuki(at)df(dot)MitsubishiElectric(dot)co(dot)jp писал 2023-06-08 02:08:
>> From: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
>> Sent: Wednesday, June 7, 2023 6:47 PM
>> This seems to be more robust, but the interface became more strange.
>> I'm not sure what to do with it. Some ideas I had to avoid introducing
>> this
>> parameter. Not sure I like any of them.
>>
>> 1) You can use QualifiedNameGetCreationNamespace() for
>> aggpartialfnName
>> and still compare namespace and function name for it and aggName,
>> aggNamespace.
>> Seems to be not ideal, but avoids introducing new parameters.
>>
>> 2) You can lookup for partial aggregate function after
>> ProcedureCreate() in
>> AggregateCreate(), if it wasn't found at earlier stages. If it is the
>> aggregate itself
>> - check it. If it's still not found, error out. Also seems to be a bit
>> ugly - you leave
>> uncommitted garbage for vacuum in catalogue.
> Thank you for suggesting alternatives.
> The disadvantages of alternative 2) appear to be undesirable,
> I have modified it according to alternative 1)
>
>> Another issue - the patch misses recording dependency between
>> aggpartialfn
>> and aggregate procedure.
> I added code to record dependencys between aggpartialfn
> and aggregate procedure, similar to the code for functions such as
> combinefunc.
>

Hi.

Looks better. The only question I have is should we record dependency
between procOid and aggpartialfn if aggpartialfn == procOid.

Also it seems new code likely should be run through pgindent.

doc/src/sgml/postgres-fdw.sgml:

+ For <literal>WHERE</literal> clauses,
+ <literal>JOIN</literal> clauses, this sending is active if
+ conditions in <xref
linkend="postgres-fdw-remote-query-optimization"/>
+ hold and <varname>enable_partitionwise_join</varname> is true(this
condition
+ is need for only <literal>JOIN</literal> clauses).
+ For aggregate expressions, this sending is active if conditions in

No space between "true" and "(" in "is true(this condition".

Some sentences in documentation, like one starting with
"For aggregate expressions, this sending is active if conditions in..."
seem to be too long, but I'm not the best man to read out documentation.

In "Built-in sharding in PostgreSQL" term "shard" doesn't have a
definition.

By the way, I'm not sure that "sharding" documentation belongs to this
patch,
at least it needs a review from native speaker.

--
Best regards,
Alexander Pyhalov,
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message o.tselebrovskiy 2023-06-08 07:53:28 Error in calculating length of encoded base64 string
Previous Message Yugo NAGATA 2023-06-08 06:38:17 Re: PG 16 draft release notes ready