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-26T21:38:44Z
Lists: pgsql-hackers

Attachments

On Sat, Mar 24, 2018 at 9:40 AM, Amit Kapila <amit.kapila16@gmail.com> wrote:
> For me, it is equivalent to the master.  The average of ten runs on
> the master is 20664.3683 and with all the patches applied it is
> 20590.4734.  I think there is some run-to-run variation, but more or
> less there is no visible degradation.  I think we have found the root
> cause and eliminated it.  OTOH, I have found another case where new
> patch series seems to degrade.

All right, I have scaled my ambitions back further.  Here is a revised
and slimmed-down version of the patch series.  If we forget about
"Remove explicit path construction logic in create_ordered_paths" for
now, then we don't really need a new upperrel.  So this patch just
modifies the toplevel scan/join rel in place, which should avoid a
bunch of overhead in add_path() and other places, while hopefully
still fixing the originally-reported problem.  I haven't tested this
beyond verifying that it passes the regression test, but I've run out
of time for today.

-- 
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.