From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Douglas Doole <dougdoole(at)gmail(dot)com>, Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: [PATCH] Push limit to sort through a subquery |
Date: | 2017-08-25 18:01:20 |
Message-ID: | 10711.1503684080@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On another note, here's a second patch applying on top of my earlier
> patch to push down Limit through Gather and Gather Merge.
I looked through this a little, and feel uncomfortable with the division
of typedefs between execnodes.h and tuplesort.h. I'm inclined to push
struct SortInstrumentation, and maybe also SharedSortInfo, into
tuplesort.h. Then tuplesort_get_stats could be given the signature
void tuplesort_get_stats(Tuplesortstate *state,
SortInstrumentation *stats);
which seems less messy. Thoughts?
I'm also pretty suspicious of the filter code you added to subselect.sql.
What happens when there's more than one worker?
(BTW, would it make sense to number the workers from 1 not 0 in the
EXPLAIN printout?)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-08-25 18:04:30 | Re: ECPG: WHENEVER statement with DO CONTINUE action |
Previous Message | Robert Haas | 2017-08-25 17:33:03 | Re: [PATCH] Push limit to sort through a subquery |