Re: Proposed refactoring of planner header files

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-01-28T21:51:11Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Mon, Jan 28, 2019 at 3:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> I'm really unhappy that force_parallel_mode and
>> parallel_leader_participation are being treated as planner GUCs.

> The only use of parallel_leader_participation at plan time seems to be
> to twiddle the costing, and the use of it in the executor is to decide
> whether to have the leader participate.  So if the values differ,
> you'll get a plan running a behavior for which plan selection was not
> optimized.  I don't know whether it's useful to intentionally allow
> this so that you can see how the same plan behaves under the other
> setting, or whether it's just a wart we'd be better off without.  It
> might be confusing, though, if you change the setting and it doesn't
> force a replan.

Well, that puts it at the ill-considered end of the spectrum instead
of the outright-broken end, but I still say it's a bad idea.  Planner
GUCs ought to control the produced plan, not other behaviors.

			regards, tom lane


Commits

  1. Refactor index cost estimation functions in view of IndexClause changes.

  2. Simplify the planner's new representation of indexable clauses a little.

  3. Move pattern selectivity code from selfuncs.c to like_support.c.

  4. Refactor planner's header files.

  5. Make some small planner API cleanups.