On Mon, Aug 24, 2026 at 6:40 AM jian he <[email protected]> wrote: > The attached patch (based on v6) is very rough; I will polish it later.
I hate to be a downer here, but I don't really understand why this feature got committed (or, well, re-committed) in the first place, and I don't understand why it hasn't been reverted yet. What does this actually do that anyone would want or find advantageous? I admit to being a skeptic of this kind of feature on general principle, so take everything I have to say here with an appropriately-sized amount of salt. But it seems to me that the major arguments for a feature like this would be if it either (1) makes the new partitions that it creates really good clones of the original partition or (2) does something to minimize data movement or (3) finds clever ways to reduce the amount of locking required. As to (1), even Alexander seems not entirely satisfied with the current behavior and proposes that it be changed in a future release, but that's a backward-incompatibility that we should be reluctant to introduce. As to (2), the source partitions are always copied in their entirety to new partitions, which is probably a pretty fair strategy when splitting a partition into equal parts or merging roughly equal-size partitions, but very non-optimal when the splits or merges are very lopsided. The point here isn't that the strategy is horrible but that there's no particular intelligence here; you can easily do the same thing by hand. As to (3), the patch takes AccessExclusiveLock on the partition parent for the entire duration of the operation. This seems non-viable in practice. I suspect that essentially 100% of users will prefer to quiesce writes to the partition to be split or merged, create new partitions with the same data, and then use ATTACH/DETACH CONCURRENTLY to do the swap. To go into a little more detail about (1), I asked Claude to analyze, in the current code, which partition properties are set from the original partition vs. which ones are set as they would be from a new partition. Basically, it says that [A] ownership is copied from the source partition(s), apparently in response to my 2024 complaint, and [B] DEPENDS ON EXTENSION markers on indexes are copied from source partitions. According to Claude, everything else is identical to what you would get with CREATE TABLE ... PARTITION OF, except that when the parent has no AM set, the default is heap rather than default_table_access_method, which is a bug. This seems like a very disappointing state of affairs, not so much because of the bug, but just because it doesn't seem at all principled. Like, why those two things, and nothing else? The ALTER INDEX .. DEPENDS ON EXTENSION thing was introduced by 713e553e321 and is a result of the fact that the indexes are re-cloned from the parent rather than the source partition -- but there is also ALTER TRIGGER ... DEPENDS ON EXTENSION, which wasn't changed. I think what almost everyone has said is that they want clone-of-source-partition behavior, not new-partition-of-parent behavior, but almost-new-partition-of-parent-but-with-a-few-random-exceptions seems almost worse. Those exceptions aren't curing the basic design problem here; they're only obscuring it. So what we have here is a feature that has none of the advantages that I listed above that might potentially make it compelling and that is also full of bugs. You can only use it if you don't mind AccessExclusiveLock for the entire operation AND the only available data-movement strategy is the right one for your use case AND your partitions are not customized in any way that makes new-partition-of-parent behavior a problem (modulo [A] and [B] in the previous paragraph). I feel like that must be very nearly the empty set of users. On top of that, Zsolt's email at the start of this thread basically said that it broke replication and was broken with generated columns, and we're now just weeks away from when we're supposed to be releasing 19 and that stuff is still broken and it's not clear that we have satisfying fixes for all of it. As I say, I'm skeptical about this kind of feature in general, so, again, take what I have to say with a grain of salt, but isn't that more than sufficient grounds for a revert? I feel like even if all the patches that we have now for all of the issues discussed on this thread are perfectly committable day (and the bit I quote from Jian above says otherwise) that still wouldn't turn this into a clean design and it would still be unclear who would want to use the feature. To be clear, I'm not trying to say that this patch needs to do every single thing that anyone could want out of a feature of this type, but it needs to do something well enough to satisfy some use case. A feature that did the clone-from-the-original-partition thing well would be usable for really small tables even if the locking behavior and data-copying were not improved. A feature that did clever things with locking and data-copying would be used in practice even if the new partitions had to be manually fixed up afterwards. But the feature we have isn't usable in either of those cases, and I can't think of a real case in which it would be usable, plus it has serious bugs four months after feature freeze. -- Robert Haas EDB: http://www.enterprisedb.com
