Re: [PATCH] Push limit to sort through a subquery

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

In response to

Responses

Browse pgsql-hackers by date

  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