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

Re: BUG #5084: Query gives different number of rows depending on ORDER BY

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk>
Cc: heikki(dot)linnakangas(at)enterprisedb(dot)com (Heikki Linnakangas), Bernt Marius Johnsen <bernt(dot)johnsen(at)sun(dot)com>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5084: Query gives different number of rows depending on ORDER BY
Date: 2009-09-28 23:10:27
Message-ID: 15833.1254179427@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-bugs
Andrew Gierth <andrew(at)tao11(dot)riddles(dot)org(dot)uk> writes:
> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>  Tom> I'm inclined to think that the best solution is to have
>  Tom> process_equivalence just reject any clauses that have equal()
>  Tom> left and right sides, ie, throw them back to be processed as
>  Tom> ordinary non-equivalence clauses.

> Hmm. Is it ever possible for mergejoinable operators to be non-strict?
> Does that matter?

I'm not sure. ISTR that nodeMergejoin makes some effort to support such
operators, but the btree code doesn't really.  In any case, it doesn't
matter.  Leaving the clause out of the equivalence machinery is
certainly safe; at worst we'll end up with a redundant test or two in
the final plan.

			regards, tom lane

In response to

Responses

pgsql-bugs by date

Next:From: Andrew GierthDate: 2009-09-29 00:28:13
Subject: Re: BUG #5084: Query gives different number of rows depending on ORDER BY
Previous:From: Andrew GierthDate: 2009-09-28 22:14:47
Subject: Re: BUG #5084: Query gives different number of rows depending on ORDER BY

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