Horton

Re: [HACKERS] why not parallel seq scan for slow functions

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Marina Polyakova <m.polyakova@postgrespro.ru>, pgsql-hackers <pgsql-hackers@postgresql.org>, Jeff Janes <jeff.janes@gmail.com>, Thomas Munro <thomas.munro@enterprisedb.com>, Amit Khandekar <amitdkhan.pg@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, Michael Paquier <michael.paquier@gmail.com>
Date: 2018-03-27T11:42:13Z
Lists: pgsql-hackers 
On Tue, Mar 27, 2018 at 1:45 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> If we don't want to go with the upperrel logic, then maybe we should
> consider just merging some of the other changes from my previous patch
> in 0003* patch you have posted and then see if it gets rid of all the
> cases where we are seeing a regression with this new approach.

Which changes are you talking about?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

Commits

  1. Rewrite the code that applies scan/join targets to paths.

  2. Teach create_projection_plan to omit projection where possible.

  3. Make the upper part of the planner work by generating and comparing Paths.