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 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers