Re: postgres_fdw behaves oddly

From: Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>
To: Ashutosh Bapat <ashutosh(dot)bapat(at)enterprisedb(dot)com>
Cc: PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: postgres_fdw behaves oddly
Date: 2014-11-11 09:45:38
Message-ID: 5461DAC2.4050400@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Ashutosh,

Thanks for the review!

(2014/11/10 20:05), Ashutosh Bapat wrote:
> Since two separate issues 1. using reltargetlist instead of attr_needed
> and 2. system columns usage in FDW are being tackled here, we should
> separate the patch into two one for each of the issues.

Agreed. Will split the patch into two.

> While I agree that the system columns shouldn't be sent to the remote
> node, it doesn't look clear to me as to what would they or their values
> mean in the context of foreign data. Some columns like tableoid would
> have a value which is the OID of the foreign table, other system columns
> like xmin/xmax/ctid will have different meanings (or no meaning)
> depending upon the foreign data source. In case of later columns, each
> FDW would have its own way of defining that meaning (I guess). But in
> any case, I agree that we shouldn't send the system columns to the
> remote side.
>
> Is there a way we can enforce this rule across all the FDWs? OR we want
> to tackle it separately per FDW?

ISTM it'd be better to tackle it separately because I feel that such an
enforcement by the PG core would go too far. I'm also concerned about a
possibility of impedance mismatching between such an enforcement and
postgres_fdw, which sends the ctid column to the remote side internally
when executing UPDATE/DELETE on foreign tables. See
postgresPlanForeignModify and eg, deparseUpdateSql.

Best regards,
Etsuro Fujita

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Etsuro Fujita 2014-11-11 10:01:04 Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
Previous Message Andres Freund 2014-11-11 09:30:55 Re: Scaling shared buffer eviction