On Wed, Apr 19, 2017 at 10:51 PM, Douglas Doole <dougdo...@gmail.com> wrote: > Thanks for the feedback Ashutosh. > > I disagree that we need to call pass_down_bound() recursively. The whole > point of the recursive call would be to tunnel through a plan node. Since > SubqueryScanState only has one child (unlike MergeAppendState) this can be > more efficiently done inline rather than via a recursive call. > > In the case of ResultState, this is classic tail-end recursion and the C > compiler should optimize it out. As we add more recursive calls though, it > becomes harder for the compiler to do the right thing. (I'll admit that I'm > not up on what state-of-the-art in recursion removal though, so maybe my > concern is moot. That said, I prefer not to depend on compiler optimizations > if there's a clean alternative way to express the code.) > > I do agree that it would make the code cleaner to handle ResultState and > SubqueryScanState in a similar fashion. My preference, however, would be to > remove the recursive call from ResultState handling. That would give us code > like: > > if child == SubqueryScanState > child = SubqueryScanState->child > else if child == ResultState > child = ResultState->child > > if child == SortState > limit pushdown > else if child == MergeAppendState > recursive call on all children > > If it is possible to get more than one SubqueryScanState and/or ResultState > between the limit and sort, then the first block of code could be placed in > a while loop. > > If you'd prefer that I rework the patch as I discussed, just let me know and > I'll resubmit it.
Thinking more about it, pass_down_bound() optimization ultimately targets sort nodes. It doesn't for example target ForeignScan nodes which can benefit from such optimization. But I think any generic LIMIT optimization will need to be handled in the planner as against the executor. Said that, I don't think community at large would accept serializing pass_down_bound() as you are proposing. You may to wait for others' opinions before working on it. If you add this to the commitfest app, more people might look at it when the next commitfest opens. Also, it might help if you can provide a query/ies with numbers where this optimization shows improvement. -- Best Wishes, Ashutosh Bapat EnterpriseDB Corporation The Postgres Database Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers