Re: inherit support for foreign tables
От | Etsuro Fujita |
---|---|
Тема | Re: inherit support for foreign tables |
Дата | |
Msg-id | 5321ABD2.6000104@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: inherit support for foreign tables (Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>) |
Ответы |
Re: inherit support for foreign tables
|
Список | pgsql-hackers |
Hi Horiguchi-san, Thank you for working this patch! (2014/03/10 17:29), Kyotaro HORIGUCHI wrote: > Hello. As a minimal implementation, I made an attempt that emit > NOTICE message when alter table affects foreign tables. It looks > like following, > > | =# 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. > I made the changes above and below as an attempt in the attached > patch foreign_inherit-v4.patch > >> I think the problem is foreign childs in inheritance tables >> prevents all menber in the inheritance relation from using >> parameterized paths, correct? Yes, I think so, too. >> 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 Best regards, Etsuro Fujita
Вложения
В списке pgsql-hackers по дате отправления: