Robert Haas <robertmh...@gmail.com> writes:
> On Sun, Oct 6, 2019 at 3:23 PM Tomas Vondra
> <tomas.von...@2ndquadrant.com> wrote:
>> Can you be more specific why you don't think this approach is not
>> useful? I'm not sure whether you consider all hooks to have this issue
>> or just this proposed one.
> I'll start by admitting that that remark was rather off-the-cuff. On
> further reflection, add_path() is not really a crazy place to try to
> add a new dimension of merit, which is really what KaiGai wants to do
> here. On the other hand, as Tom and I noted upthread, that system is
> creaking under its weight as it is, and making it extensible seems
> like it might therefore be a bad idea - specifically, because it might
> slow down planning quite a bit on large join problems, either because
> of the additional cost testing the additional dimension of merit or
> because of the additional cost of dealing with the extra paths that
> get kept.
FWIW, I think that the patch as proposed would most certainly have
nasty performance problems. To make intelligent decisions, the
hook function would basically have to re-do a large fraction of
the calculations that add_path itself does. It's also fairly
unclear (or at least undocumented) how things would work if multiple
path providers wanted to make use of the hook; except that that
performance issue would get worse, as each of them redoes that work.
Also, as Robert says, the real goal here is to allow some additional
comparison dimension to be considered. Simply preventing pre-existing
paths from being removed isn't sufficient for that --- you have to be
able to change the accept_new decisions as well, as Tomas already
worried about. But if we phrase that as an additional hook that
only concerns itself with accept_new, then the duplicate-calculation
problem gets really substantially worse: I think actual use of a hook
like that would require reconsidering the entire existing path list.
I'm not very sure what a good design for adding new comparison dimensions
would look like, but I think this isn't it.
We could imagine, maybe, that a hook for the purpose of allowing an
additional dimension to be considered would be essentially a path
comparison function, returning -1, +1, or 0 depending on whether
path A is dominated by path B (on this new dimension), dominates
path B, or neither. However, I do not see how multiple extensions
could usefully share use of such a hook.
regards, tom lane
