Hi,
On Fri, Oct 3, 2025 at 5:51 PM Etsuro Fujita <etsuro.fujita@gmail.com> wrote:
>
> Sorry, I don't fully understand you here, but I think that when
> updating a foreign table via ForeignModify, we 1) should retrieve
> tabloid from the remote if the foreign table points to a remote
> partitioned/inherited table, and 2) should not otherwise, to avoid
> useless data transmission. Is that possible?
I'm very new to the optimizer/planner code, so I haven't been able to
achieve this. In my previous letter I told, that we can retrieve tableoid
and compare it with the oid of the remote table. If they are not matched, we
will know that the remote table is partitioned. Then we can refresh some
meta info (for example a new field in ForeignTable structure) in order
to be sure that tableoid is needed in the future. And vice versa, we can
understand that tableoid is not needed.
So the answer to your question is "no" by now. Because I don't see any
sane way to figure out whether the remote table is partitioned.
>
> > > I wonder whether we'd be better off thinking of a way to let FDWs
> > > invent additional system column IDs for their tables, so that
> > > something like a remote table OID could be represented in the
> > > natural way as a Var with negative varattno.
> >
> > May I ask you to tell me more details? As far as I understand, if
> > postgres_fdw doesn't use direct modify, it will hardcode query like
> > this anyway :
> > appendStringInfoString(buf, "DELETE FROM ");
> > deparseRelation(buf, rel);
> > appendStringInfoString(buf, " WHERE ctid = $1");
> >
> > At the moment when we set the ctid in this way, the situation inevitably
> > moves towards an error.
> >
> > Are you suggesting using another condition for the WHERE clause in
> > this case (based on the new "remote table oid" column)?
>
> No, he is mentioning how we should manage tableoid retrieved from the
> remote during query execution (from ForeignScan node to ModifyTable
> node), and yes, if we addressed this, we could modify the deparser
> code to add a "tableoid = X" constraint to the WHERE condition when
> updating a remote partitioned/inherited tale.
>
OK, I got it. Thanks!
So far, I've just been examining your patch and found that it doesn't apply
on the newest master and fails the regression tests. I attach rebased +
the corrected (in the sense of passing tests) version of your patch.
I hope it will be usable. I had also add new test to the postgres_fdw.sql
to show that the described problem doesn't occur anymore.
The main problem of my version of the patch is that tableoid requests may
be redundant. But since the problem is important for us, I'll continue working
on it.
--
Best regards,
Daniil Davydov
