Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>, Rajkumar Raghuwanshi <rajkumar(dot)raghuwanshi(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Expression errors with "FOR UPDATE" and postgres_fdw with partition wise join enabled.
Date: 2018-07-02 09:46:35
Message-ID: 5B39F47B.10707@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

(2018/06/22 23:58), Robert Haas wrote:
> I think this approach is going to run into trouble if the level at
> which we have to apply the ConvertRowTypeExpr happens not to be a
> projection-capable node.

Actually, the level we have to do that would be a child rel of a
partitioned table or a child join of a partitionwise join, so the plan
node would be a scan or join plan unless the child rel or child join is
itself partitioned, in which case the plan node would be
Append/MergeAppend and the proposed patch recursively would apply that
conversion to child plans for the Append/MergeAppend).

> And, in general, it seems to me that we want
> to produce the right outputs at the lowest possible level of the plan
> tree. For instance, suppose that one of the relations being scanned
> is not parallel-safe but the others are. Then, we could end up with a
> plan like this:
>
> Append
> -> Seq Scan on temp_rela
> -> Gather
> -> Parallel Seq Scan on thing1
> -> Gather
> -> Parallel Seq Scan on thing2
>
> If a projection is required to convert the row type expression, we
> certainly want that to get pushed below the Gather, not to happen at
> the Gather level itself.

IIUC, we currently don't consider such a plan for partition-wise join;
we'll only consider gathering partial paths for the parent appendrel.
So, I'm not sure we need to take into account that when applying the
ConvertRowtypeExpr. Maybe I'm missing something, though.

> We certainly don't want it to happen at the
> Append level, which can't even handle it.

I think so too.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Konstantin Knizhnik 2018-07-02 09:59:57 Re: Global shared meta cache
Previous Message Ashutosh Sharma 2018-07-02 09:46:21 Test-cases for deferred constraints in plpgsql_transaction.sql