On Mon, Aug 21, 2017 at 5:08 AM, Amit Kapila <amit.kapil...@gmail.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers