From: | David Rowley <david(dot)rowley(at)2ndquadrant(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mathias Kunter <mathiaskunter(at)gmail(dot)com>, pgsql-bugs(at)postgresql(dot)org |
Subject: | Re: BUG #14107: Major query planner bug regarding subqueries and indices |
Date: | 2016-04-29 01:16:12 |
Message-ID: | CAKJS1f_xd0to95CdY7J05PXPzxTKRmXx=PScWyG-e28w6qNeRw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
On 29 April 2016 at 13:10, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> I don't actually see any way to do very much with your second example at
> all:
>
>> SELECT ... FROM a JOIN b ON (...) WHERE a.x = ? OR b.y = ?;
>
> There's no way to push anything down to either the A or B scans from
> that WHERE condition: you can't remove any rows before the join because
> they might join to rows on the other side that satisfy the other half
> of the OR.
I was confused when I read that too. The only way I thought to
transform would be to create a UNION for each condition, which in
theory would be possible providing the SELECT lists contained the PK
columns. Of course, in practice this would be difficult, since UNIONs
are planned later, and having the query execute in that way would have
to be costed, and only used if cheaper.
--
David Rowley http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | kayzizz | 2016-04-29 01:38:40 | BUG #14120: Documentation suggestion 35.4.2 |
Previous Message | Tom Lane | 2016-04-29 01:10:38 | Re: BUG #14107: Major query planner bug regarding subqueries and indices |