Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
От | Andres Freund |
---|---|
Тема | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode |
Дата | |
Msg-id | 20210323191307.twhewx7vqj2ocglv@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode (Amit Kapila <amit.kapila16@gmail.com>) |
Ответы |
Re: pgsql: Add a new GUC and a reloption to enable inserts in parallel-mode
|
Список | pgsql-committers |
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
В списке pgsql-committers по дате отправления: