Re: disable only nonparallel seq scan.
От | Robert Haas |
---|---|
Тема | Re: disable only nonparallel seq scan. |
Дата | |
Msg-id | CA+TgmoYWWJ+vmLGhP0FDBer8O6sVri8hvfjV8PsFC6RnyTV6jg@mail.gmail.com обсуждение исходный текст |
Ответ на | disable only nonparallel seq scan. (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: disable only nonparallel seq scan.
|
Список | pgsql-hackers |
On Sun, Dec 8, 2019 at 1:24 PM Jeff Janes <jeff.janes@gmail.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-parallelone? > > Usually I can do things like with with enable_* setting, but if I `set enable_seqscan to off`, it penalizes the parallelseq 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 Iwant 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 thepurpose, which is to see what the "would have been" plan estimates are for the parallel seq scan under the default settingof the cost parameters. > > I can creep parallel_tuple_cost downward until it switches, and then try to extrapolate back up, but this tedious and notvery 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
В списке pgsql-hackers по дате отправления: