David Rowley <dgrowleyml@gmail.com> writes:
> ... What I mean is that as we add
> more and more fixes to improve performance of partitioning, that there
> comes a point where the ability to directly reference partitions is a
> hindrance rather than something that's useful. Right now that
> hindrance is the fact that we must lock every single partition in the
> plan. We only need to do that in case some other backend is doing
> something that bypasses taking a lock on the parent partitioned table.
TBH, I buy no part of that line of reasoning. I don't think that the
ability to access partitions directly is a material problem here;
I doubt that we need to lock every partition in the plan when run-time
routing is working (surely we only need to lock the partition mapping);
and most especially I don't see why an operation on a child table that
doesn't lock the parent would cause a problem for queries that do not
need to access that child. Perhaps we've got some implementation issues
to fix, but I see no fundamental problem there.
It is true that this design can lead to deadlocks between operations that
start from the parent vs ones that start from the child and then discover
that they need to lock the parent. But the latter should be darn rare.
In any case, your solution seems to amount to prohibiting not only the
latter class of operations altogether, but *also* prohibiting operations
on the child that don't need to lock the parent. I fail to see how that
makes anybody's life better.
regards, tom lane