On Tue, Apr 27, 2021 at 10:51 AM Bharath Rupireddy <bharath.rupireddyforpostg...@gmail.com> wrote: > > > I still feel that why we shouldn't limit the declarative approach to > only partitioned tables? And for normal tables, possibly with a > minimal cost(??), the server can do the safety checking. I know this > feels a little inconsistent. In the planner we will have different > paths like: if (partitioned_table) { check the parallel safety tag > associated with the table } else { perform the parallel safety of the > associated objects }. >
Personally I think the simplest and best approach is just do it consistently, using the declarative approach across all table types. > > Then, running the pg_get_parallel_safety will have some overhead if > there are many partitions associated with a table. And, this is the > overhead planner would have had to incur without the declarative > approach which we are trying to avoid with this design. > The big difference is that pg_get_parallel_safety() is intended to be used during development, not as part of runtime parallel-safety checks (which are avoided using the declarative approach). So there is no runtime overhead associated with pg_get_parallel_safety(). > > I'm thinking that when users say ALTER TABLE partioned_table SET > PARALLEL TO 'safe';, we check all the partitions' and their associated > objects' parallel safety? If all are parallel safe, then only we set > partitioned_table as parallel safe. What should happen if the parallel > safety of any of the associated objects/partitions changes after > setting the partitioned_table safety? > With the declarative approach, there is no parallel-safety checking on either the CREATE/ALTER when the parallel-safety is declared/set. It's up to the user to get it right. If it's actually wrong, it will be detected at runtime. Regards, Greg Nancarrow Fujitsu Australia