On Wed, Mar 24, 2021 at 12:30 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> How about a declarative approach instead? That is, if a user would
> like parallelized inserts into a partitioned table, she must declare
> the table parallel-safe with some suitable annotation. Then, checking
> the property during DML is next door to free, and instead we have to think
> about whether and how to enforce that the marking is valid during DDL.
>
> I don't honestly see a real cheap way to enforce such a property.
> For instance, if someone does ALTER FUNCTION to remove a function's
> parallel-safe marking, we can't really run around and verify that the
> function is not used in any CHECK constraint. (Aside from the cost,
> there would be race conditions.)
>
> But maybe we don't have to enforce it exactly. It could be on the
> user's head that the marking is accurate. We could prevent any
> really bad misbehavior by having parallel workers error out if they
> see they've been asked to execute a non-parallel-safe function.
>
> Or there are probably other ways to slice it up. But I think some
> outside-the-box thinking might be helpful here.
It's a possibility. It's a bit different from my decision to mark
functions as PARALLEL SAFE/RESTRICTED/UNSAFE because, if you wanted to
deduce that without an explicit marking, you'd need to solve the
halting problem, which I've heard is fairly difficult. In this case,
though, the problem is solvable with a linear-time algorithm. It's
possible that there is nothing better, but I'm not sure.
One idea would be to try to cache some state in shared memory. That
wouldn't work for an unbounded number of relations, at least not
unless we used DSA, but you could have a hash table with a
configurable number of slots and make the default big enough that it
would bother few people in practice. There might be some other details
about partitioned relations that would be useful to cache, too.
--
Robert Haas
EDB: http://www.enterprisedb.com