Re: Partial aggregates pushdown

From: Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>
To: Bruce Momjian <bruce(at)momjian(dot)us>
Cc: "Fujii(dot)Yuki(at)df(dot)MitsubishiElectric(dot)co(dot)jp" <Fujii(dot)Yuki(at)df(dot)mitsubishielectric(dot)co(dot)jp>, 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-20 06:59:11
Message-ID: f47c4cb0965a8de2a19322970e7ba7e3@postgrespro.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Bruce Momjian писал 2023-06-20 03:42:
> Apologies for the delay in my reply to this email. I looked into the
> existing code and I found three things:
>
> 1) PQserverVersion() just pulls the conn->sversion value from the
> existing connection because pqSaveParameterStatus() pulls the
> server_version sent by the backend; no need to issue SELECT version().
>
> 2) postgres_fdw already has nine calls to GetConnection(), and only
> opens a connection if it already doesn't have one. Here is an example:
>
> /* Get the remote estimate */
> conn = GetConnection(fpinfo->user, false, NULL);
> get_remote_estimate(sql.data, conn, &rows, &width,
> &startup_cost, &total_cost);
> ReleaseConnection(conn);
>
> Therefore, it seems like it would be near-zero cost to just call conn =
> GetConnection() and then PQserverVersion(conn), and
> ReleaseConnection().
> You can then use the return value of PQserverVersion() to determine if
> you can push down partial aggregates.
>

Hi.
Currently we don't get remote connection while planning if
use_remote_estimate is not set.
Such change would require to get remote connection in planner, not in
executor.
This can lead to change of behavior (like errors in explain when user
mapping is wrong - e.g. bad password is specified).
Also this potentially can lead to establishing connections even when
plan node is not actually used
(like extreme example - select sum(score) from t limit 0).
I'm not saying we shouldn't do it - just hint at possible consequences.

--
Best regards,
Alexander Pyhalov,
Postgres Professional

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jeff Davis 2023-06-20 09:02:36 collation-related loose ends before beta2
Previous Message Will Mortensen 2023-06-20 06:32:46 [PATCH] doc: add missing mention of MERGE in MVCC