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 15:15:02 |
Message-ID: | 1125.1503674102@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:
> However, there's another opportunity for optimization here, which is
> the Limit -> Gather -> Anything case. A worker which has itself
> generated enough tuples to fill the limit can certainly stop working,
> but right now it doesn't know that. The patch I posted before didn't
> think about that case, but it seems to require only trivial
> modifications.
Ah, good point.
> I was going to post an updated patch trying to
> address that, but I see that you've already posted something, so I'll
> go have a look at that instead.
The problem I exhibited with the updated patch could probably be resolved
if the top level logic in a parallel worker knows about tuples_needed
and doesn't try to pull more than that from its subplan. So what you're
describing isn't just an additional optimization, it's necessary to make
this work at all.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-08-25 15:43:51 | Re: [PATCH] Push limit to sort through a subquery |
Previous Message | Robert Haas | 2017-08-25 15:11:28 | Re: [PATCH] Push limit to sort through a subquery |