Re: why not parallel seq scan for slow functions

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>
Cc: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: why not parallel seq scan for slow functions
Date: 2017-08-25 16:38:37
Message-ID: CA+TgmoZx+pgv-W9iVcg_RAaMRUTwa89t1PP_8zX60HdQstDpfQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Mon, Aug 21, 2017 at 5:08 AM, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> wrote:
> Thanks for acknowledging the idea. I have written a patch which
> implements the above idea. At this stage, it is merely to move the
> discussion forward. Few things which I am not entirely happy about
> this patch are:
>
> (a) To skip generating gather path for top level scan node, I have
> used the number of relations which has RelOptInfo, basically
> simple_rel_array_size. Is there any problem with it or do you see any
> better way?

I'm not sure.

> (b) I have changed the costing of gather path for path target in
> generate_gather_paths which I am not sure is the best way. Another
> possibility could have been that I change the code in
> apply_projection_to_path as done in the previous patch and just call
> it from generate_gather_paths. I have not done that because of your
> comment above thread ("is probably unsafe, because it might confuse
> code that reaches the modified-in-place path through some other
> pointer (e.g. code which expects the RelOptInfo's paths to still be
> sorted by cost)."). It is not clear to me what exactly is bothering
> you if we directly change costing in apply_projection_to_path.

The point I was trying to make is that if you retroactively change the
cost of a path after you've already done add_path(), it's too late to
change your mind about whether to keep the path. At least according
to my current understanding, that's the root of this problem in the
first place. On top of that, add_path() and other routines that deal
with RelOptInfo path lists expect surviving paths to be ordered by
descending cost; if you frob the cost, they might not be properly
ordered any more.

I don't really have time right now to give this patch the attention
which it deserves; I can possibly come back to it at some future
point, or maybe somebody else will have time to give it a look.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Alexander Kuzmenkov 2017-08-25 16:41:25 Re: PoC: full merge join on comparison clause
Previous Message Robert Haas 2017-08-25 16:27:18 Re: [PATCH] Push limit to sort through a subquery