Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-24 Thread David Steele
Hi Kaigai, On 3/21/17 1:11 PM, David Steele wrote: On 3/13/17 3:25 AM, Jeevan Chalke wrote: I have reviewed this patch further and here are my comments: This thread has been idle for over a week. Please respond and/or post a new patch by 2017-03-24 00:00 AoE (UTC-12) or this submission

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-21 Thread David Steele
Hi, On 3/13/17 3:25 AM, Jeevan Chalke wrote: I have reviewed this patch further and here are my comments: This thread has been idle for over a week. Please respond and/or post a new patch by 2017-03-24 00:00 AoE (UTC-12) or this submission will be marked "Returned with Feedback".

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-13 Thread Jeevan Chalke
Hi, I have reviewed this patch further and here are my comments: 1. Will it be better to use compare_pathkeys() instead of equal(root->query_pathkeys, pathkeys)? 2. I think it will be good if we add a simple test-case in postgres_fdw.sql which shows that LIMIT is passed to remote server. We

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-12 Thread Kouhei Kaigai
> Hello, > > On Wed, March 1, 2017 7:21 pm, Kouhei Kaigai wrote: > >> I've looked at the patch, and as I'm not that familiar with the > >> pg-sourcecode, customs and so on, this isn't a review, more like food > >> for thought and all should be taken with a grain of salt. :) > >> > >> So here are

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-10 Thread Tels
Hello, On Wed, March 1, 2017 7:21 pm, Kouhei Kaigai wrote: >> I've looked at the patch, and as I'm not that familiar with the >> pg-sourcecode, >> customs and so on, this isn't a review, more like food for thought and >> all >> should be taken with a grain of salt. :) >> >> So here are a few

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-01 Thread Kouhei Kaigai
> Hello all, > > as this is my first mail to pgsql-hackers, please be gentle :) > Welcome to pgsql-hackers, > I've looked at the patch, and as I'm not that familiar with the pg-sourcecode, > customs and so on, this isn't a review, more like food for thought and all > should be taken with a grain

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-03-01 Thread Tels
Hello all, as this is my first mail to pgsql-hackers, please be gentle :) I've looked at the patch, and as I'm not that familiar with the pg-sourcecode, customs and so on, this isn't a review, more like food for thought and all should be taken with a grain of salt. :) So here are a few

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-02-28 Thread Kouhei Kaigai
ujita > <fujita.ets...@lab.ntt.co.jp>; Andres Freund <and...@anarazel.de> > Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan > [take-2] > > Oops, I oversight this patch was marked as "returned with feedback", not > "moved to t

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-01-04 Thread Michael Paquier
On Thu, Jan 5, 2017 at 8:58 AM, Kouhei Kaigai wrote: > Unfortunately, it was not possible. Probably, administrator privilege will be > needed for this operation. Adding a patch to a CF in progress indeed requires administrator privileges, > May I add it to the CF:2017-03?

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-01-04 Thread Kouhei Kaigai
.jp.nec.com>; Jeevan Chalke > <jeevan.cha...@enterprisedb.com>; pgsql-hackers@postgresql.org; Etsuro > Fujita <fujita.ets...@lab.ntt.co.jp>; Andres Freund <and...@anarazel.de> > Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan > [take-2] > >

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-01-04 Thread Robert Haas
On Mon, Jan 2, 2017 at 10:07 PM, Kohei KaiGai wrote: > Oops, I oversight this patch was marked as "returned with feedback", > not "moved to the next CF". > > Its status has not been changed since the last update. (Code was > revised according to the last > comment by Jeevan,

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2017-01-02 Thread Kohei KaiGai
Oops, I oversight this patch was marked as "returned with feedback", not "moved to the next CF". Its status has not been changed since the last update. (Code was revised according to the last comment by Jeevan, but CF-Nov was time up at that time.) How do I handle the patch? 2016-12-05 16:49

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-12-04 Thread Kouhei Kaigai
Hello, Sorry for my late response. The attached patch reflects your comments. > Here are few comments on latest patch: > > > 1. > make/make check is fine, however I am getting regression failure in > postgres_fdw contrib module (attached regression.diff). > Please investigate and fix. > It was

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-12-01 Thread Haribabu Kommi
On Thu, Nov 10, 2016 at 10:59 AM, Kouhei Kaigai wrote: > > On Tue, Nov 8, 2016 at 6:54 AM, Jeevan Chalke > > wrote: > > > 1. ps_numTuples is declared as long, however offset and count members > in > > > LimitState struct and bound member in

[HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-24 Thread Jeevan Chalke
On Mon, Nov 21, 2016 at 1:59 PM, Kouhei Kaigai wrote: > Hello, > > The attached patch is a revised version of pass-down LIMIT to FDW/CSP. > > Below is the updates from the last version. > > 'ps_numTuples' of PlanState was declared as uint64, instead of long > to avoid

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-21 Thread Kouhei Kaigai
Hello, The attached patch is a revised version of pass-down LIMIT to FDW/CSP. Below is the updates from the last version. 'ps_numTuples' of PlanState was declared as uint64, instead of long to avoid problems on 32bits machine when a large LIMIT clause is supplied. 'ps_numTuples' is

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-09 Thread Kouhei Kaigai
> On Tue, Nov 8, 2016 at 6:54 AM, Jeevan Chalke > wrote: > > 1. ps_numTuples is declared as long, however offset and count members in > > LimitState struct and bound member in SortState struct is int64. However > > long on 32 bit machine may be 32 bits and thus I

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-09 Thread Kouhei Kaigai
ita; Andres Freund > Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2] > > On Mon, Oct 31, 2016 at 10:20 AM, Kouhei Kaigai <kai...@ak.jp.nec.com> wrote: > > As an example, I enhanced postgres_fdw to understand the ps_numTuples > > if it is se

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-09 Thread Robert Haas
On Tue, Nov 8, 2016 at 6:54 AM, Jeevan Chalke wrote: > 1. ps_numTuples is declared as long, however offset and count members in > LimitState struct and bound member in SortState struct is int64. However > long on 32 bit machine may be 32 bits and thus I think

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-09 Thread Robert Haas
On Mon, Oct 31, 2016 at 10:20 AM, Kouhei Kaigai wrote: > As an example, I enhanced postgres_fdw to understand the ps_numTuples > if it is set. If and when remote ORDER BY is pushed down, the latest > code tries to sort the entire remote table because it does not know > how

Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-11-08 Thread Jeevan Chalke
Hi, I have reviewed the patch. Patch applies cleanly. make/"make install"/"make check" all are fine. I too see a good performance in execution time when LIMIT is pushed with cursor query in postgres_fdw at execution time However here are few comments on the changes: 1. ps_numTuples is

[HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2]

2016-10-31 Thread Kouhei Kaigai
Hello, The attached patch is revised version of the pass-down-bounds feature. Its functionality is not changed from the previous version, however, implementation was revised according to the discussion at the last CF. This patch add a new fields (ps_numTuples) to the PlanState. This is a hint