Re: disable only nonparallel seq scan.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Jeff Janes <jeff(dot)janes(at)gmail(dot)com>
Cc: pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: disable only nonparallel seq scan.
Date: 2019-12-10 18:32:03
Message-ID: CA+TgmoYWWJ+vmLGhP0FDBer8O6sVri8hvfjV8PsFC6RnyTV6jg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes <jeff(dot)janes(at)gmail(dot)com> wrote:
> Is there a way to force a meaningful parallel seq scan, or at least the planning of one, when the planner wants a non-parallel one?
>
> Usually I can do things like with with enable_* setting, but if I `set enable_seqscan to off`, it penalizes the parallel seq scan 8 times harder than it penalizes the non-parallel one, so the plan does not switch.
>
> If I set `force_parallel_mode TO on` then I do get a parallel plan, but it is a degenerate one which tells me nothing I want to know.
>
> If I `set parallel_tuple_cost = 0` (or in some cases to a negative number), I can force it switch, but that destroys the purpose, which is to see what the "would have been" plan estimates are for the parallel seq scan under the default setting of the cost parameters.
>
> I can creep parallel_tuple_cost downward until it switches, and then try to extrapolate back up, but this tedious and not very reliable.

I don't think there's a way to force this, but setting both
parallel_setup_cost and parallel_tuple_cost to 0 seems to often be
enough.

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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-12-10 18:40:39 Re: Statistics improvements for time series data
Previous Message Alvaro Herrera 2019-12-10 18:08:21 Re: xact_start for walsender & logical decoding not updated