From: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(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-13 13:00:02 |
Message-ID: | 5321ABD2.6000104@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
Attachment | Content-Type | Size |
---|---|---|
foreign_inherit-v6.patch | text/plain | 51.5 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | Andrew Dunstan | 2014-03-13 13:08:43 | Re: jsonb and nested hstore |
Previous Message | Greg Stark | 2014-03-13 12:42:00 | Re: jsonb and nested hstore |