Re: why not parallel seq scan for slow functions

Robert Haas <robertmhaas(at)gmail(dot)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