pgsql: Still another try at fixing scanjoin_target insertion into paral

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: pgsql-committers(at)postgresql(dot)org
Subject: pgsql: Still another try at fixing scanjoin_target insertion into paral
Date: 2016-06-18 04:29:01
Message-ID: E1bE7sT-000098-34@gemulon.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-committers

Still another try at fixing scanjoin_target insertion into parallel plans.

The previous code neglected the fact that the scanjoin_target might
carry sortgroupref labelings that we need to absorb. Instead, do
create_projection_path() unconditionally, and tweak the path's cost
estimate after the fact. (I'm now convinced that we ought to refactor
the way we account for sometimes not needing a separate projection step,
but right now is not the time for that sort of cleanup.)

Problem identified by Amit Kapila, patch by me.

Branch
------
master

Details
-------
http://git.postgresql.org/pg/commitdiff/598aa194af2fb7f294ae4b029494a134a44be333

Modified Files
--------------
src/backend/optimizer/plan/planner.c | 39 ++++++++++++++-------------
src/test/regress/expected/select_parallel.out | 18 ++++++++++++-
src/test/regress/sql/select_parallel.sql | 6 ++++-
3 files changed, 43 insertions(+), 20 deletions(-)

Browse pgsql-committers by date

  From Date Subject
Next Message Tom Lane 2016-06-18 04:36:12 Re: pgsql: Try again to fix the way the scanjoin_target is used with partia
Previous Message Amit Kapila 2016-06-18 03:48:21 Re: pgsql: Try again to fix the way the scanjoin_target is used with partia