Re: inherit support for foreign tables - Mailing list pgsql-hackers

From Kyotaro HORIGUCHI
Subject Re: inherit support for foreign tables
Date
Msg-id 20140317.173044.254841983.horiguchi.kyotaro@lab.ntt.co.jp
Whole thread Raw
In response to Re: inherit support for foreign tables  (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>)
Responses Re: inherit support for foreign tables
List 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



pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: Fix typo in nbtree.h introduced by efada2b
Next
From: KONDO Mitsumasa
Date:
Subject: Re: gaussian distribution pgbench