Hi,
On 2021-03-23 09:01:13 +0530, Amit Kapila wrote:
> 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?
You cache it. And actually use information that is already
cached. There's a huge difference between doing expensive stuff once
every now and then, and doing it over and over and over. That's why we
have relcache, syscache, typecache etc.
> 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)?
Most of those seem more about risk-reduction. And they don't have
reloptions - which seems to be the only way this feature can
realistically be used. The one halfway comparable GUC is
enable_partitionwise_join - while it'd be great to not need it (or at
least not default to off), it implies some legitimately computationally
hard work that can't easily be cached.
Greetings,
Andres Freund