Re: [HACKERS] why not parallel seq scan for slow functions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] why not parallel seq scan for slow functions
Date
Msg-id 9268.1503682095@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] why not parallel seq scan for slow functions  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> 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.

Hadn't been paying attention to this thread, but I happened to notice
Robert's comment here, and I strongly agree: it is *not* cool to be
changing a path's cost (or, really, anything else about it) after
it's already been given to add_path.  add_path has already made
irreversible choices on the basis of what it was given.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: [HACKERS] [PATCH] Push limit to sort through a subquery
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Update comment in ExecPartitionCheck