On 2017/10/26 16:40, Etsuro Fujita wrote:
Other changes I made
to the executor are: (1) currently, we set the RT index for the root
partitioned table to ri_RangeTableIndex of partitions' ResultRelInfos,
but the proposed EXPLAIN requires that the partition's
ri_RangeTableIndex is set to the RT
Hi Maksim,
On 2017/10/02 21:37, Maksim Milyutin wrote:
On 11.09.2017 16:01, Etsuro Fujita wrote:
* Query planning: the patch creates copies of Query/Plan with a
foreign partition as target from the original Query/Plan for each
foreign partition and invokes PlanForeignModify with those copies,
Hi Fujita-san!
On 11.09.2017 16:01, Etsuro Fujita wrote:
Here is an updated version of the patch.
* Query planning: the patch creates copies of Query/Plan with a
foreign partition as target from the original Query/Plan for each
foreign partition and invokes PlanForeignModify with those
On 2017/08/17 17:27, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
I have to admit that I'm a little bit fuzzy about why foreign insert
routing requires all of these changes. I think this patch would
benefit from being accompanied by several paragraphs of explanation
outlining
On 2017/08/26 1:43, Robert Haas wrote:
On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
wrote:
I agree, but I wonder if we ought to make it work first using the
existing APIs and then add these new APIs as an optimization.
I'm not sure that's a good idea because
On Sun, Aug 20, 2017 at 11:25 PM, Etsuro Fujita
wrote:
>> I agree, but I wonder if we ought to make it work first using the
>> existing APIs and then add these new APIs as an optimization.
>
> I'm not sure that's a good idea because that once we support INSERT
>
On 2017/08/19 2:12, Robert Haas wrote:
On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita
wrote:
I think that would be much more efficient than INSERTing tuples into the
remote server one by one. What do you think about that?
I agree, but I wonder if we ought to
On 2017/08/18 22:41, David Fetter wrote:
On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote:
On 2017/08/17 23:48, David Fetter wrote:
On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro
On Thu, Aug 17, 2017 at 4:27 AM, Etsuro Fujita
wrote:
> I think that would be much more efficient than INSERTing tuples into the
> remote server one by one. What do you think about that?
I agree, but I wonder if we ought to make it work first using the
existing APIs
On Thu, Aug 17, 2017 at 7:58 AM, Etsuro Fujita
wrote:
>> The description seems to support only COPY to a foreign table from a
>> file, but probably we need the support other way round as well. This
>> looks like a feature (support copy to and from a foreign table) to
On Fri, Aug 18, 2017 at 05:10:29PM +0900, Etsuro Fujita wrote:
> On 2017/08/17 23:48, David Fetter wrote:
> >On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
> >>On 2017/07/11 6:56, Robert Haas wrote:
> >>>On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
>
On 2017/08/17 23:48, David Fetter wrote:
On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
wrote:
So, I dropped the COPY part.
Ouch. I think we should try to
On Thu, Aug 17, 2017 at 05:27:05PM +0900, Etsuro Fujita wrote:
> On 2017/07/11 6:56, Robert Haas wrote:
> >On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
> > wrote:
> >>So, I dropped the COPY part.
> >
> >Ouch. I think we should try to figure out how the COPY part
On 2017/08/17 20:37, Ashutosh Bapat wrote:
On Thu, Aug 17, 2017 at 1:57 PM, Etsuro Fujita
wrote:
I spent some time on this. To handle that, I'd like to propose doing
something similar to \copy (frontend copy): submit a COPY query "COPY ...
FROM STDIN" to the
On Thu, Aug 17, 2017 at 1:57 PM, Etsuro Fujita
wrote:
> On 2017/07/11 6:56, Robert Haas wrote:
>>
>> On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
>> wrote:
>>>
>>> So, I dropped the COPY part.
>>
>>
>> Ouch. I think we should try to
On 2017/07/11 6:56, Robert Haas wrote:
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
wrote:
So, I dropped the COPY part.
Ouch. I think we should try to figure out how the COPY part will be
handled before we commit to a design.
I spent some time on this. To
On Thu, Jun 29, 2017 at 6:20 AM, Etsuro Fujita
wrote:
> So, I dropped the COPY part.
Ouch. I think we should try to figure out how the COPY part will be
handled before we commit to a design.
I have to admit that I'm a little bit fuzzy about why foreign insert
On 2017/07/05 9:13, Amit Langote wrote:
On 2017/06/29 20:20, Etsuro Fujita wrote:
In relation to this, I also allowed expand_inherited_rtentry() to
build an RTE and AppendRelInfo for each partition of a partitioned table
that is an INSERT target, as mentioned by Amit in [1], by modifying
Fujita-san,
On 2017/06/29 20:20, Etsuro Fujita wrote:
> Hi,
>
> Here is a patch for $subject. This is based on Amit's original patch
> (patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]).
Thanks a lot for taking this up.
> Main changes are:
>
> * I like Amit's idea that for
Hi,
Here is a patch for $subject. This is based on Amit's original patch
(patch '0007-Tuple-routing-for-partitioned-tables-15.patch' in [1]).
Main changes are:
* I like Amit's idea that for each partition that is a foreign table,
the FDW performs query planning in the same way as in
20 matches
Mail list logo