From: | Douglas Doole <dougdoole(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | 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-24 05:51:41 |
Message-ID: | CADE5jY+SbwhkkLh_kGrmgPUGBawaYTwJCk1Y=xX6Fn-VTe8OTA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>
> Here's a not-really-tested draft patch for that.
>
I don't know the parallel code so I'm not going to comment on the overall
patch, but a thought on ExecSetTupleBound().
That function is getting a number of cases where we're doing recursion for
a single child (result, gather, gather-merge). Recursion for a single child
isn't particularly efficient. I know that if there's a single case of
recursion like this, compilers will frequently turn it into a loop, but I
don't know if compilers can optimize a branched case like this.
Would we be better off moving those cases into the while loop I added to
avoid the recursion? So we'd end up with something like:
while ()
{
if subquery
else if result
else if gather
else if gather merge
}
if sort
else if merge append
And a nit from my original fix now that I've looked at the pg10 code more.
The two casts I added (to SubqueryScanState and Node) should probably be
changed to castNode() calls.
- Doug
Salesforce
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2017-08-24 06:53:10 | Re: proposal: psql command \graw |
Previous Message | Michael Paquier | 2017-08-24 05:25:45 | Re: Combination with priority-based and quorum-based synchronous replications |