Skip site navigation (1) Skip section navigation (2)

Re: BUG #4926: too few pathkeys for mergeclauses

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Greg Stark <gsstark(at)mit(dot)edu>, Roman Kononov <kononov(at)ftml(dot)net>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #4926: too few pathkeys for mergeclauses
Date: 2009-07-17 18:36:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-bugs
I wrote:
> I think what this case may show is simply that the consistency
> checking I added to create_mergejoin_plan in 8.3 is too strict.
> Not quite convinced yet though.

After further review I think that is the correct approach to take.

The proximate cause of the problem is that
find_mergeclauses_for_pathkeys is selecting an order for the merge
clauses that corresponds to a noncanonical pathkey list for the
inner relation (to wit, x, y, x).  While it would be possible in
this particular example to put the clauses in x, x, y order instead,
I don't think that is necessarily possible in every case.  The clause
ordering is constrained by the outer pathkeys and what we have here
is a demonstration that the inner pathkeys needn't match the outer
ones one-to-one.  So you could have a clause that references an inner
pathkey that is also referenced by some earlier clause that matches
a different outer pathkey, and there won't be any way to make them

By the time the plan gets to create_mergejoin_plan, the inner pathkey
list has been reduced to canonical form (x, y), but *this does not
represent any actual change in sort order*.  (Which is why there's
no actual bug in 8.2 and before, which blithely generate plans that
involve such "incorrect" mergeclause orderings.)  So I think we should
just weaken the checks in create_mergejoin_plan to allow such cases,
ie, each mergeclause should be allowed to match any already-used
inner pathkey.

The other approach we could possibly take is to have
find_mergeclauses_for_pathkeys reject candidate mergeclauses that
produce out-of-order inner pathkeys, but that would break at least
this Assert at joinpath.c:272:

        /* Should have used them all... */
        Assert(list_length(cur_mergeclauses) == list_length(mergeclause_list));

and it'd be rather expensive to test for anyway.

			regards, tom lane

In response to

pgsql-bugs by date

Next:From: Euler Taveira de OliveiraDate: 2009-07-17 19:50:02
Subject: Re: BUG #4927: psql does "spoil" the query before sending it to server
Previous:From: Frank van VugtDate: 2009-07-17 18:06:50
Subject: Re: bug or simply not enough stack space?

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group