Re: [HACKERS] [PATCH] Push limit to sort through a subquery - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [HACKERS] [PATCH] Push limit to sort through a subquery
Date
Msg-id CA+Tgmob2teRuvV7UTiBPt_q7+yMJMXMRn9ThCbL3jrvEO0PwUA@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] [PATCH] Push limit to sort through a subquery  (Douglas Doole <dougdoole@gmail.com>)
Responses Re: [HACKERS] [PATCH] Push limit to sort through a subquery  (Douglas Doole <dougdoole@gmail.com>)
List pgsql-hackers
On Fri, Aug 18, 2017 at 11:42 AM, Douglas Doole <dougdoole@gmail.com> wrote:
> Thanks for the feedback on my original patch Robert. Here's an updated patch
> that will tunnel through multiple SubqueryScanStates.

Seems reasonable.  I have some assorted nitpicks.

1. The header comment for pass_down_bound() could mention "one or more
levels of subqueries" rather than "a subquery".

2. The first of the comments in the function body appears to have a
whitespace issue that needs to be fixed manually or, better yet,
addressed by pgindent.

3. The formatting of the comment in the regression tests appears to be
unlike any other comment in that same file.

4. I am pretty doubtful that "Memory: 25kB" is going to be stable
enough for us to want that output memorialized in the regression
tests. It seems like it might vary on different platforms - e.g.
32-bit vs. 64-bit - and it also seems like minor changes to how we do
sorting could perturb it and, perhaps, make it unstable even if today
it isn't.  So I think it would be good to give this a bit more thought
and see if you can come up with a way to test this without running
afoul of that problem.  Maybe adapt from this:

do $$declare x text; begin execute 'explain select 1' into x; if x !~
'^Result' then raise notice '%', x; else raise notice 'looks ok'; end
if; end;$$;

BTW, regarding the other patch on this thread, it struck me that maybe
it would be better to just reduce/limit the fetch count for the cursor
instead of trying to inject LIMIT n into the query itself.  That's not
as good for query optimization purposes but it's a lot more
future-proof.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



pgsql-hackers by date:

Previous
From: Dilip Kumar
Date:
Subject: Re: [HACKERS] why not parallel seq scan for slow functions
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Stats for triggers on partitioned tables not shown in EXPLAIN ANALYZE