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
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 |