On 2018/10/09 19:05, Michael Paquier wrote: > On Tue, Oct 09, 2018 at 06:41:59PM +0900, Amit Langote wrote: >> Partitioned indexes, just like partitioned tables, don't have their own >> storage, so pg_relation_size() cannot be used to obtain their size. We >> decided that the correct way to get the partitioned table's size is *not* >> to modify pg_relation_size itself to internally find all partitions and >> sum their sizes, but to provide a function that returns partitions and >> tell users to write SQL queries around it to calculate the total size. >> I'm saying that the new function should be able to be used with >> partitioned indexes too. > > I have to admit that I find the concept non-intuitive. A partition tree > is a set of partitions based on a root called a partitioned table. A > partitioned index is not a partition, it is a specific object which is > associated to a partitioned table without any physical on-disk presence. > An index is not a partition as well, it is an object associated to one > relation.
I see it as follows: a partitioned index *does* have partitions and the partitions in that case are index objects, whereas, a partitioned table's partitions are table objects. IOW, I see the word "partition" as describing a relationship, not any specific object or kind of objects. > I am not saying that there is no merit in that. I honestly don't know, > but being able to list all the partitioned tables and their partition > tables looks enough to cover all the grounds discussed, and there is no > need to work out more details for a new clone of find_all_inheritors and > get_partition_ancestors. Sorry if I'm misunderstanding something, but why would we need a new clone? If we don't change pg_partition_tree() to only accept tables (regular/partitioned/foreign tables) as input, then the same code can work for indexes as well. As long as we store partition relationship in pg_inherits, same code should work for both. Thanks, Amit
