On Thu, Jun 20, 2013 at 12:19 AM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp > wrote:
> > From: Hitoshi Harada [mailto:umi.tan...@gmail.com] > > > I guess the patch works fine, but what I'm saying is it might be limited > to > > small use cases. Another instance of this that I can think of is ORDER > BY > clause > > of window specifications, which you may want to remove from the target > list > > as well, in addition to ORDER BY of query. It will just not be removed > by > this > > approach, simply because it is looking at only parse->sortClause. > Certainly > > you can add more rules to the new function to look at the window > specification, > > but then I'm not sure what we are missing. > > Yeah, I thought the extension to the window ORDER BY case, too. But I'm > not > sure it's worth complicating the code, considering that the objective of > this > optimization is to improve full-text search related things if I understand > correctly, though general solutions would be desirable as you mentioned. > > Ah, I see the use case now. Makes sense. > > So, as it stands it doesn't have > > critical issue, but more generalized approach would be desirable. That > said, > > I don't have strong objection to the current patch, and just posting one > thought > > to see if others may have the same opinion. > > OK. I'll also wait for others' comments. For review, an updated version > of the > patch is attached, which fixed the bug using the approach that directly > uses the > clause information in the parse tree. > > > I tried several ways but I couldn't find big problems. Small typo: s/rejunk/resjunk/ I defer to commiter. Thanks, -- Hitoshi Harada
