On Mon, Mar 22, 2021 at 8:03 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>
> Robert Haas <robertmhaas@gmail.com> writes:
> > I find this fairly ugly. If you can't make the cost of checking
> > whether parallelism is safe low enough that you don't need a setting
> > for this, then I think perhaps you shouldn't have the feature at all.
> > In other words, I propose that you revert both this and 05c8482f7f and
> > come back when you have a better design that doesn't introduce so much
> > overhead.
>
> I'm +1 on that idea for a completely independent reason: 05c8482f7f
> is currently the easy winner for "scariest patch of the v14 cycle".
> I don't have any faith in it, and so I'm very concerned that it went
> in so late in the dev cycle. It'd be better to push some successor
> design early in the v15 cycle, when we'll have more time to catch
> problems.
>
Okay, I can revert this work to avoid that risk but it would be great
if you can share your thoughts on what alternative design do you have
in mind, and or how it should be better implemented? Regarding
performance overhead, it is for partitioned tables with a large number
of partitions, and that too when the data to insert is not that much
or there is parallel-unsafe clause on one of the partitions. Now, how
else can we determine the parallel-safety without checking each of the
partitions? We do have other partition-related gucs
(enable_partition*) to avoid the partitions-related overhead so why is
it so bad to have guc here (maybe the naming of guc/reloption is not
good)?
--
With Regards,
Amit Kapila.
