Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables
От | Robert Haas |
---|---|
Тема | Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables |
Дата | |
Msg-id | CA+TgmoZ=eEPDkk2W+B12Cu_xVeWqys7X=b+2wZu7HD5qWj8jYQ@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables (Michael Paquier <michael.paquier@gmail.com>) |
Ответы |
Re: [Sender Address Forgery]Re: pg_(total_)relation_size andpartitioned tables
|
Список | pgsql-hackers |
On Fri, Jan 26, 2018 at 7:45 AM, Michael Paquier <michael.paquier@gmail.com> wrote: > There could be value in having a version dedicated to inheritance trees > as well, true enough. As well as value in having something that shows > both. Still let's not forget that partition sets are structured so as > the parents have no data, so I see more value in having only partitions > listed, without the INHERIT part. Opinions from others are of course > welcome. Well, partitioning and inheritance can't be mixed. A given table has either partitions OR inheritance children OR neither. If it has either partitions or inheritance children, find_all_inheritors will return them. Otherwise, I think it'll just return the input OID itself. So I don't quite see, if we're going to add a convenience function here, why wouldn't just define it to return the same results as find_all_inheritors does? -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: