On Fri, Jul 28, 2017 at 9:30 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > 0004 patch > The patch adds another column partdefid to catalog pg_partitioned_table. The > column gives OID of the default partition for a given partitioned table. This > means that the default partition's OID is stored at two places 1. in the > default partition table's pg_class entry and in pg_partitioned_table. There is > no way to detect when these two go out of sync. Keeping those two in sync is > also a maintenance burdern. Given that default partition's OID is required > only > while adding/dropping a partition, which is a less frequent operation, it > won't > hurt to join a few catalogs (pg_inherits and pg_class in this case) to find > out > the default partition's OID. That will be occasional performance hit > worth the otherwise maintenance burden.
Performance isn't the only consideration here. We also need to think about locking and concurrency. I think that most operations that involve locking the parent will also involve locking the default partition. However, we can't safely build a relcache entry for a relation before we've got some kind of lock on it. We can't assume that there is no concurrent DDL going on before we take some lock. We can't assume invalidation messages are processed before we have taken some lock. If we read multiple catalog tuples, they may be from different points in time. If we can figure out everything we need to know from one or two syscache lookups, it may be easier to verify that the code is bug-free vs. having to do something more complicated. Now that having been said, I'm not taking the position that Jeevan's patch (based on Amit Langote's idea) has definitely got the right idea, just that you should think twice before shooting down the approach. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers