Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery - Mailing list pgsql-performance

From Gavin Wahl
Subject Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
Date
Msg-id CACPudh0h1tvujVnas=4D-b+JsWy2d8CVO761v5558c+P-50LWg@mail.gmail.com
Whole thread Raw
In response to Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-performance
> (3) is an instance of seeing "a = b and b = c" and deducing "a = c" from
> that. (4) does not follow that pattern, so it's outside the realm of what the
> planner can deduce.

I see, that makes sense. I assumed there was something more complex going on in
the background.  What about converting (1) into (2)? I know the planner does
something kind of similar, in converting

  SELECT * FROM (SELECT * FROM x WHERE a) WHERE b

into

  SELECT * FROM (SELECT * FROM x WHERE a AND b)

I guess in this case it would have to know about unique indexes to prove that
if the primary keys are equal, all the other columns are too. My intention in
trying (3) was to take that burden of proof off the planner.

pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: Planner Conceptual Error when Joining a Subquery -- Outer Query Condition not Pulled Into Subquery
Next
From: Ken Tanzer
Date:
Subject: Re: BASH script for collecting analyze-related info