Message-ID: <5CA1B659.1050908@lab.ntt.co.jp>
Date: Mon, 01 Apr 2019 15:57:29 +0900
From: Etsuro Fujita <fujita.etsuro@lab.ntt.co.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;
 rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
Subject: Re: BUG #15724: Can't create foreign table as partition
References: <20190329141050.GA22336@alvherre.pgsql>
 <5CA1A320.4050707@lab.ntt.co.jp>
 <038a0fec-6684-c654-bade-bcf80cb8daad@lab.ntt.co.jp>
In-Reply-To: <038a0fec-6684-c654-bade-bcf80cb8daad@lab.ntt.co.jp>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Alvaro Herrera <alvherre@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>,
        stepya@ukr.net, pgsql-bugs@lists.postgresql.org
Precedence: bulk

(2019/04/01 15:23), Amit Langote wrote:
> 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@2ndquadrant.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.

Yeah, I think so.  Another benefit I can think of would be: that would 
probably allow us to support ON CONFLICT DO UPDATE for foreign tables. 
I think the intended benefit would be large!

Best regards,
Etsuro Fujita