On Thu, Jun 10, 2021 at 10:59 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Thu, Jun 10, 2021 at 12:54 AM Amit Kapila <amit.kapila16@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/TYAPR01MB29905A9AB82CC8BA50AB0F80FE709@TYAPR01MB2990.jpnprd01.prod.outlook.com
[2] - https://www.postgresql.org/message-id/1030301.1616560249%40sss.pgh.pa.us
--
With Regards,
Amit Kapila.