Re: BUG #17964: Missed query planner optimization - Mailing list pgsql-bugs

From David Rowley
Subject Re: BUG #17964: Missed query planner optimization
Date
Msg-id CAApHDvpj1rjTsOn34K0W9WpVptQHJkMQHt+db0FVWOxVK0OewQ@mail.gmail.com
Whole thread Raw
In response to BUG #17964: Missed query planner optimization  (PG Bug reporting form <noreply@postgresql.org>)
Responses Re: BUG #17964: Missed query planner optimization  (Mathias Kunter <mathiaskunter@gmail.com>)
List pgsql-bugs
On Wed, 7 Jun 2023 at 04:44, PG Bug reporting form
<noreply@postgresql.org> wrote:
> In the example below, the query planner uses a sequential scan (query 1)
> even though it could use an index scan (query 2).
>
> EXPLAIN ANALYZE SELECT id, name FROM (SELECT id, name FROM table1 UNION
> SELECT id, name FROM table2) AS q
> WHERE id IN (SELECT id FROM table3);

> EXPLAIN ANALYZE SELECT id, name FROM (SELECT id, name FROM table1 UNION
> SELECT id, name FROM table2) AS q
> WHERE id IN (1538,8836,5486,3464,2673);

It's not a bug that the planner does not consider evaluating the join
before the UNION, it's just an optimisation opportunity we don't
currently explore.

If you want that, then write:

EXPLAIN ANALYZE SELECT id, name FROM table1 WHERE id IN (SELECT id
FROM table3) UNION SELECT id, name FROM table2 WHERE id IN (SELECT id
FROM table3);

David



pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #17963: Recursive table cannot be referenced when using LEFT JOIN instead of LATERAL in recursive term
Next
From: PG Bug reporting form
Date:
Subject: BUG #17965: SIGSEGV from LLVM13 JIT when executing SQL.