Horton

Re: On partitioning

Robert Haas <robertmhaas@gmail.com>

View thread View on postgr.es
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
Cc: Andres Freund <andres@2ndquadrant.com>, Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, Bruce Momjian <bruce@momjian.us>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2014-12-11T01:32:49Z
Lists: pgsql-hackers 
On Wed, Dec 10, 2014 at 7:25 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> In heap_create(), do we create storage for a top level partitioned table (say, RELKIND_PARTITIONED_TABLE)? How about a partition that is further sub-partitioned? We might allocate storage for a partition at some point and then later choose to sub-partition it. In such a case, perhaps, we would have to move existing data to the storage of subpartitions and deallocate the partition's storage. In other words only leaf relations in a partition hierarchy would have storage. Is there such a notion within code for some other purpose or we'd have to invent it for partitioning scheme?

I think it would be advantageous to have storage only for the leaf
partitions, because then you don't need to waste time doing a
zero-block sequential scan of the root as part of the append-plan, an
annoyance of the current system.

We have no concept for this right now; in fact, right now, the relkind
fully determines whether a given relation has storage.  One idea is to
make the leaves relkind = 'r' and the interior notes some new relkind.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company