On Wed, Mar 16, 2016 at 2:25 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
> Robert Haas <robertmh...@gmail.com> writes:
>> On Wed, Mar 16, 2016 at 2:02 PM, Tom Lane <t...@sss.pgh.pa.us> wrote:
>>> Looks pretty close. One point is that if we do end up using a Result
>>> node, then the parent GatherPath does not get charged for the Result
>>> node's cpu_per_tuple overhead. I'm not sure that that's worth changing
>>> though. It's probably better to bet that the subpath is projectable and
>>> so no cost will ensue, than to bet the other way.
>> I'm almost sure this way is the better bet.
> Actually, we do know what will happen ... so maybe
> * We always use create_projection_path here, even if the subpath is
> * projection-capable, so as to avoid modifying the subpath in place.
> * It seems unlikely at present that there could be any other
> * references to the subpath anyway, but better safe than sorry.
> + if (!is_projection_capable_path(gpath->subpath))
> + gpath->path.total_cost += cpu_tuple_cost * gpath->subpath->rows;
> gpath->subpath = (Path *)
> The comment could use adjustment if you adopt that, to reference the fact
> that we know create_projection_plan will get rid of the Result if not
OK, I've committed something along those lines. Thanks for the
advice, and feel free to whack it around if you have an idea for
improving it further - though IMHO this is good enough for 9.6.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: