Re: PassDownLimitBound for ForeignScan/CustomScan [take-2]
От | Kouhei Kaigai |
---|---|
Тема | Re: PassDownLimitBound for ForeignScan/CustomScan [take-2] |
Дата | |
Msg-id | 9A28C8860F777E439AA12E8AEA7694F80125634C@BPXM15GP.gisp.nec.co.jp обсуждение исходный текст |
Ответ на | Re: PassDownLimitBound for ForeignScan/CustomScan [take-2] (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
> -----Original Message----- > From: pgsql-hackers-owner@postgresql.org > [mailto:pgsql-hackers-owner@postgresql.org] On Behalf Of Robert Haas > Sent: Thursday, November 10, 2016 3:08 AM > To: Kaigai Kouhei(海外 浩平) > Cc: pgsql-hackers@postgresql.org; Jeevan Chalke; Etsuro Fujita; Andres Freund > Subject: Re: [HACKERS] PassDownLimitBound for ForeignScan/CustomScan [take-2] > > On Mon, Oct 31, 2016 at 10:20 AM, Kouhei Kaigai <kaigai@ak.jp.nec.com> 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 many rows to be returned. Thus, it took larger execution time. > > On the other hands, the patched one runs the remote query with LIMIT > > clause according to the ps_numTuples; which is informed by the Limit > > node on top of the ForeignScan node. > > So there are two cases here. If the user says LIMIT 12, we could in > theory know that at planner time and optimize accordingly. If the > user says LIMIT twelve(), however, we will need to wait until > execution time unless twelve() happens to be capable of being > simplified to a constant by the planner. > > Therefore, it's possible to imagine having two mechanisms here. In the > simple case where the LIMIT and OFFSET values are constants, we could > implement a system to get hold of that information during planning and > use it for whatever we like. In addition, we can have an > execution-time system that optimizes based on values available at > execution (regardless of whether those values were also available > during planning). Those are, basically, two separate things, and this > patch has enough to do just focusing on one of them. > OK, we need to have a private value of postgres_fdw to indicate whether LIMIT and OFFSET were supplied at the planner stage. If any, it has to be matched with the ps_numTuples informed at the executor stage. I'll revise the patch. -- NEC OSS Promotion Center / PG-Strom Project KaiGai Kohei <kaigai@ak.jp.nec.com>
В списке pgsql-hackers по дате отправления: