From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Benjamin Reed <ranger(at)opennms(dot)org> |
Cc: | pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #4934: regression in IN with joins in subselect |
Date: | 2009-07-23 00:34:47 |
Message-ID: | 5972.1248309287@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Benjamin Reed <ranger(at)opennms(dot)org> writes:
> Attached is a test case, including the query that causes the error at
> the end. On 8.3, it returns 1 row (192.168.1.1), on 8.4 including the
> git 8.4 branch, it returns none.
Thanks, it seems like the problem is that it's applying *both* its
methods for implementing an IN join: it's unique-ifying the sub-select
output via a HashAggregate, and then using a Semi Join anyway when that
gets joined to the "node" table. And the Semi Join has indeterminate
output for some of the other output columns. (The join order it's
choosing seems a bit odd too, but with so few rows in the tables it may
be that all the join orders seem to have the same cost.) I think this
is probably a small fix, but running out of energy for tonight ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Lauris Ulmanis | 2009-07-23 10:47:47 | Postgres user authentification or LDAP authentification |
Previous Message | Benjamin Reed | 2009-07-22 21:31:56 | Re: BUG #4934: regression in IN with joins in subselect |