On Mon, Aug 7, 2017 at 1:48 AM, Ashutosh Bapat
<ashutosh.bapat@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
