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 по дате отправления:

Предыдущее
От: Peter Geoghegan
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)
Следующее
От: Robert Haas
Дата:
Сообщение: Re: [HACKERS] Parallel tuplesort (for parallel B-Tree index creation)