Re: inherit support for foreign tables
От | Kyotaro HORIGUCHI |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 20140317.173044.254841983.horiguchi.kyotaro@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>) |
Ответы |
Re: inherit support for foreign tables
|
Список | 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 по дате отправления: