From: | Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp> |
---|---|
To: | Etsuro Fujita <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)jp>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, stepya(at)ukr(dot)net, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #15724: Can't create foreign table as partition |
Date: | 2019-04-01 06:23:15 |
Message-ID: | 038a0fec-6684-c654-bade-bcf80cb8daad@lab.ntt.co.jp |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 2019/04/01 14:35, Etsuro Fujita wrote:
> (2019/03/29 23:10), Alvaro Herrera wrote:
>> On 2019-Mar-29, Tom Lane wrote:
>>
>>> Alvaro Herrera<alvherre(at)2ndquadrant(dot)com> writes:
>>>> On 2019-Mar-29, PG Bug reporting form wrote:
>>>>> SQL Error [42809]: ERROR: cannot create index on foreign table
>>>>> "msg_json"
>
>>> Really, what *ought* to happen in such a case is that the FDW gets
>>> told about the command and has the opportunity to try to do something
>>> corresponding to making an index.
>
> Interesting!
+1
Maybe, CHECK constraints on foreign tables are similar -- it merely
asserts the condition that all of the rows in the remote table *must*
satisfy so that the local server can do something useful with it, such as
trying to exclude the table with constraint exclusion.
I guess the intended benefit with allowing indexes would be similar -- a
locally-defined index on a foreign table will help an FDW estimate the
cost of a query accessing the table more efficiently than, for example,
having to rely on some other relatively expensive alternative, such as
use_remote_estimate in postgres_fdw's case.
Thanks,
Amit
From | Date | Subject | |
---|---|---|---|
Next Message | PG Bug reporting form | 2019-04-01 06:32:07 | BUG #15725: pgAgent not working on Another database other than Postgres |
Previous Message | Etsuro Fujita | 2019-04-01 06:01:50 | Re: BUG #15724: Can't create foreign table as partition |