From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: convert EXSITS to inner join gotcha and bug |
Date: | 2017-04-28 16:29:18 |
Message-ID: | CAKJS1f9GLO4+sULDrJEC9+Qksb3gyYDUemtkg2n0oOr8nXsD6g@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
(On 29 April 2017 at 02:26, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru> writes:
>> I've reproduced this bug on d981074c.
>> On default config, after loading example.sql.bz2 and VACUUM ANALYZE, query
>> result is OK.
>> But with seqscan and hashjoin disabled, query returns 0 rows.
>
> Ah, thanks for the clue about enable_hashjoin, because it wasn't
> reproducing for me as stated.
>
> It looks like in the case that's giving wrong answers, the mergejoin
> is wrongly getting marked as "Inner Unique". Something's a bit too ()
> cheesy about that planner logic --- not sure what, yet.
Seems related to the unconditional setting of extra.inner_unique to
true for JOIN_UNIQUE_INNER jointypes in add_paths_to_joinrel()
Setting this based on the return value of innerrel_is_unique() as done
with the other join types seems to fix the issue.
I don't know yet if that's the correct fix. It's pretty late 'round
this side to be thinking too hard about it.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Dmitriy Sarafannikov | 2017-04-28 16:32:35 | Re: [PROPOSAL] Use SnapshotAny in get_actual_variable_range |
Previous Message | Robert Haas | 2017-04-28 16:28:26 | Re: Logical replication in the same cluster |