On Thu, Jun 10, 2021 at 10:59 PM Robert Haas <robertmh...@gmail.com> wrote: > > On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila <amit.kapil...@gmail.com> wrote: > > Fair enough. So, I think there is a consensus to drop this patch and > > if one wants then we can document these cases. Also, we don't want it > > to enable parallelism for Inserts where we are trying to pursue the > > approach to have a flag in pg_class which allows users to specify > > whether writes are allowed on a specified relation. > > +1. The question that's still on my mind a little bit is whether > there's a reasonable alternative to forcing users to set a flag > manually. It seems less convenient than having to do the same thing > for a function, because most users probably only create functions > occasionally, but creating tables seems like it's likely to be a more > common operation. Plus, a function is basically a program, so it sort > of feels reasonable that you might need to give the system some hints > about what the program does, but that doesn't apply to a table. > > Now, if we forget about partitioned tables here for a moment, I don't > really see why we couldn't do this computation based on the relcache > entry, and then just cache the flag there? >
Do we invalidate relcache entry if someone changes say trigger or some index AM function property via Alter Function (in our case from safe to unsafe or vice-versa)? Tsunakawa-San has mentioned this as the reason in his email [1] why we can't rely on caching this property in relcache entry. I also don't see anything in AlterFunction which would suggest that we invalidate the relation with which the function might be associated via trigger. The other idea in this regard was to validate the parallel safety during DDL instead of relying completely on the user but that also seems to have similar hazards as pointed by Tom in his email [2]. I think it would be good if there is a way we can do this without asking for user input but if not then we can try to provide parallel-safety info about relation which will slightly ease the user's job. Such a function would check relation (and its partitions) to see if there exists any parallel-unsafe clause and accordingly return the same to the user. Now, again if the user changes the parallel-safe property later we won't be able to automatically reflect the same for rel. [1] - https://www.postgresql.org/message-id/tyapr01mb29905a9ab82cc8ba50ab0f80fe...@tyapr01mb2990.jpnprd01.prod.outlook.com [2] - https://www.postgresql.org/message-id/1030301.1616560249%40sss.pgh.pa.us -- With Regards, Amit Kapila.