On Tue, Jun 15, 2021 at 7:31 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Tue, Jun 15, 2021 at 7:05 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Okay, but I think if we go with your suggested model where whenever > > there is a change in parallel-safety of any function, we need to send > > the new invalidation then I think it won't matter whether the function > > is associated with index expression, check constraint in the table, or > > is used in any other way. > > No, it will still matter, because I'm proposing that the > parallel-safety of functions that we only access via operator classes > will not even be checked. >
I am not very clear on what exactly you have in your mind in this regard. I understand that while computing parallel-safety for a rel we don't need to consider functions that we only access via operator class but how do we distinguish such functions during Alter Function? Is there a simple way to deduce that this is an operator class function so don't register invalidation for it? Shall we check it via pg_depend? > > > We can additionally check the > > parallel safety of partitions when we are trying to insert into a > > particular partition and error out if we detect any parallel-unsafe > > clause and we are in parallel-mode. So, in this case, we won't be > > completely relying on the users. Users can either change the parallel > > safe option of the table or remove/change the parallel-unsafe clause > > after error. The new invalidation message as we are discussing would > > invalidate the parallel-safety for individual partitions but not the > > root partition (partitioned table itself). For root partition, we will > > rely on information specified by the user. > > Yeah, that may be the best we can do. Just to be clear, I think we > would want to check whether the relation is still parallel-safe at the > start of the operation, but not have a run-time check at each function > call. > Agreed, that is what I also had in mind. > > I am not sure if we have a simple way to check the parallel safety of > > partitioned tables. In some way, we need to rely on user either (a) by > > providing an option to specify whether parallel Inserts (and/or other > > DMLs) can be performed, or (b) by providing a guc and/or rel option > > which indicate that we can check the parallel-safety of all the > > partitions. Yet another option that I don't like could be to > > parallelize inserts on non-partitioned tables. > > If we figure out a way to check the partitions automatically that > actually works, we don't need a switch for it; we can (and should) > just do it that way all the time. But if we can't come up with a > correct algorithm for that, then we'll need to add some kind of option > where the user declares whether it's OK. > Yeah, so let us think for some more time and see if we can come up with something better for partitions, otherwise, we can sort out things further in this direction. -- With Regards, Amit Kapila.
