pgsql: Change more places to be less trusting of RestrictInfo.is_pushed

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)lists(dot)postgresql(dot)org
Subject: pgsql: Change more places to be less trusting of RestrictInfo.is_pushed
Date: 2018-04-20 19:19:43
Message-ID: E1f9bZP-00074X-PN@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Change more places to be less trusting of RestrictInfo.is_pushed_down.

On further reflection, commit e5d83995e didn't go far enough: pretty much
everywhere in the planner that examines a clause's is_pushed_down flag
ought to be changed to use the more complicated behavior where we also
check the clause's required_relids. Otherwise we could make incorrect
decisions about whether, say, a clause is safe to use as a hash clause.

Some (many?) of these places are safe as-is, either because they are
never reached while considering a parameterized path, or because there
are additional checks that would reject a pushed-down clause anyway.
However, it seems smarter to just code them all the same way rather
than rely on easily-broken reasoning of that sort.

In support of that, invent a new macro RINFO_IS_PUSHED_DOWN that should
be used in place of direct tests on the is_pushed_down flag.

Like the previous patch, back-patch to all supported branches.

Discussion: https://postgr.es/m/f8128b11-c5bf-3539-48cd-234178b2314d@proxel.se

Branch
------
REL9_6_STABLE

Details
-------
https://git.postgresql.org/pg/commitdiff/64ad85860ce6b3a7ce01a392f90a322bf61d068f

Modified Files
--------------
src/backend/optimizer/path/costsize.c | 10 ++++++++--
src/backend/optimizer/path/joinpath.c | 4 ++--
src/backend/optimizer/path/joinrels.c | 30 +++++++++++++++++-------------
src/backend/optimizer/plan/analyzejoins.c | 6 ++----
src/backend/optimizer/plan/initsplan.c | 5 +++++
src/backend/optimizer/util/restrictinfo.c | 12 ++----------
src/include/nodes/relation.h | 17 ++++++++++++++++-
7 files changed, 52 insertions(+), 32 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2018-04-20 20:00:52 pgsql: Tweak a couple of planner APIs to save recalculating join relids
Previous Message Andrew Dunstan 2018-04-19 22:30:09 Re: pgsql: Fix incorrect handling of join clauses pushed into parameterized