Re: why not parallel seq scan for slow functions
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jeff Janes <jeff.janes@gmail.com>,
Thomas Munro <thomas.munro@enterprisedb.com>, Amit Khandekar <amitdkhan.pg@gmail.com>, Dilip Kumar <dilipbalaut@gmail.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-11-07T21:21:55Z
Lists: pgsql-hackers
On Mon, Nov 6, 2017 at 9:57 PM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> Well, I suppose that test will fire for a baserel when the total >> number of baserels is at least 3 and there's no inheritance involved. >> But if there are 2 baserels, we're still not the topmost scan/join >> target. > > No, if there are 2 baserels, then simple_rel_array_size will be 3. > The simple_rel_array_size is always the "number of relations" plus > "one". See setup_simple_rel_arrays. Oh, wow. That's surprising. >> Also, even if inheritance is used, we might still be the >> topmost scan/join target. > > Sure, but in that case, it won't generate the gather path here (due to > this part of check "!root->append_rel_list"). I am not sure whether I > have understood the second part of your question, so if my answer > appears inadequate, then can you provide more details on what you are > concerned about? I don't know why the question of why root->append_rel_list is empty is the relevant thing here for deciding whether to generate gather paths at this point. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
Commits
-
Rewrite the code that applies scan/join targets to paths.
- 11cf92f6e2e1 11.0 landed
-
Teach create_projection_plan to omit projection where possible.
- d7c19e62a8e0 11.0 landed
-
Make the upper part of the planner work by generating and comparing Paths.
- 3fc6e2d7f5b6 9.6.0 cited