Re: inherit support for foreign tables

From: Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>
To: fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp
Cc: shigeru(dot)hanada(at)gmail(dot)com, pgsql-hackers(at)postgresql(dot)org
Subject: Re: inherit support for foreign tables
Date: 2014-03-17 08:30:44
Message-ID: 20140317.173044.254841983.horiguchi.kyotaro@lab.ntt.co.jp
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Fujita-san,

> Thank you for working this patch!

No problem, but my point seems always out of the main target a bit:(

> > | =# alter table passwd add column added int, add column added2 int;
> > | NOTICE: This command affects foreign relation "cf1"
> > | NOTICE: This command affects foreign relation "cf1"
> > | ALTER TABLE
> > | =# select * from passwd;
> > | ERROR: missing data for column "added"
> > | CONTEXT: COPY cf1, line 1: "root:x:0:0:root:/root:/bin/bash"
> > | =#
> >
> > This seems far better than silently performing the command,
> > except for the duplicated message:( New bitmap might required to
> > avoid the duplication..
>
> As I said before, I think it would be better to show this kind of
> information on each of the affected tables whether or not the affected
> one is foreign. I also think it would be better to show it only when
> the user has specified an option to do so, similar to a VERBOSE option
> of other commands. ISTM this should be implemented as a separate
> patch.

Hmm. I *wish* this kind of indication to be with this patch even
only for foreign tables which would have inconsistency
potentially. Expanding to other objects and/or knobs are no
problem to be added later.

> >> Hmm. I tried minimal implementation to do that. This omits cost
> >> recalculation but seems to work as expected. This seems enough if
> >> cost recalc is trivial here.
>
> I think we should redo the cost/size estimate, because for example,
> greater parameterization leads to a smaller rowcount estimate, if I
> understand correctly. In addition, I think this reparameterization
> should be done by the FDW itself, becasuse the FDW has more knowledge
> about it than the PG core. So, I think we should introduce a new FDW
> routine for that, say ReparameterizeForeignPath(), as proposed in
> [1]. Attached is an updated version of the patch. Due to the above
> reason, I removed from the patch the message displaying function you
> added.
>
> Sorry for the delay.
>
> [1]
> http://www.postgresql.org/message-id/530C7464.6020006@lab.ntt.co.jp

I had a rough look on foreign reparameterize stuff. It seems ok
generally.

By the way, Can I have a simple script to build an environment to
run this on?

regards,

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message KONDO Mitsumasa 2014-03-17 08:40:35 Re: gaussian distribution pgbench
Previous Message Magnus Hagander 2014-03-17 08:10:00 Re: Fix typo in nbtree.h introduced by efada2b