Re: join pushdown and issue with foreign update

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Andrey Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, Alexander Pyhalov <a(dot)pyhalov(at)postgrespro(dot)ru>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: join pushdown and issue with foreign update
Date: 2021-06-04 23:23:04
Message-ID: 451345.1622848984@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Amit Langote <amitlangote09(at)gmail(dot)com> writes:
> On Wed, Jun 2, 2021 at 4:39 PM Andrey Lepikhov
> <a(dot)lepikhov(at)postgrespro(dot)ru> wrote:
>> I played with your patch and couldn't find any errors. But what if ROW
>> operation were allowed to be pushed to a foreign server?
>> Potentially, I can imagine pushed-down JOIN with arbitrary ROW function
>> in its target list.

I thought about this for awhile and I don't think it's a real concern.
There's nothing stopping us from pushing an expression of the form
"func(row(...))" or "row(...) op row(...)", because we're not asking
to retrieve the value of the ROW() expression. Whether the remote
server can handle that is strictly its concern. (Probably, it's
going to do something involving a locally-assigned typmod to keep
track of the rowtype, but it's not our problem.) Where things get
sticky is if we try to *retrieve the value* of a ROW() expression.
And except in this specific context, I don't see why we'd do that.
There's no advantage compared to retrieving the component Vars
or expressions.

> ... I wonder if it would make sense to also
> check varattno == 0 here somewhere for good measure.

Yeah, I considered doing that but left it off in this version.
It's not clear to me how there could be a table column of type RECORD,
so it seemed unnecessary. On the other hand, it's also cheap
insurance, so I'll put it back.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Alvaro Herrera 2021-06-04 23:35:33 Re: logical decoding bug: segfault in ReorderBufferToastReplace()
Previous Message Alvaro Herrera 2021-06-04 23:21:11 Re: Move pg_attribute.attcompression to earlier in struct for reduced size?