On Mon, Aug 7, 2017 at 1:48 AM, Ashutosh Bapat <ashutosh.ba...@enterprisedb.com> wrote: > with the way schema is designed. May be it's better to use your idea > of using get_rel_relkind() or find a way to check that the flag is in > sync with the relkind, like when building the relcache.
That's got the same problem as building a full relcache entry: cache bloat. It will have *less* cache bloat, but still some. Maybe it's little enough to be tolerable; not sure. But we want this system to scale to LOTS of partitions eventually, so building on a design that we know has scaling problems seems a bit short-sighted. > I noticed that find_all_inheritors() uses a hash table to eliminate > duplicates arising out of multiple inheritance. Partition hierarchy is > never going to have multiple inheritance, and doesn't need to > eliminate duplicates and so doesn't need the hash table. It will be > good, if we can eliminate that overhead. But that's separate task than > what this thread is about. I don't want to eliminate that overhead. If the catalog is manually modified or corrupted, the problem could still occur, and result in backend crashes or, at best, incomprehensible errors. The comments allude to this problem. -- 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
