Re: Examples required in || 5.10. Table Partitioning - Mailing list pgsql-docs

On Thu, Feb  6, 2020 at 12:23:46PM +0000, PG Doc comments form wrote:
> The following documentation comment has been logged on the website:
>
> Page: https://www.postgresql.org/docs/12/ddl-partitioning.html
> Description:
>
> Hello ,
>
> As I'm searching for the official documentation of Hash Partition and List
> Partition with example with more description the only information is found
> is  as below :
>
> List Partitioning
> The table is partitioned by explicitly listing which key values appear in
> each partition.
>
> Hash Partitioning
> The table is partitioned by specifying a modulus and a remainder for each
> partition. Each partition will hold the rows for which the hash value of the
> partition key divided by the specified modulus will produce the specified
> remainder.
>
> But how to create and manage these above 2 partition is not explained in
> documentation properly officially.for further information related to these 2
> partition we need to search private blogs,because of lack of information
> provided in the documentation 5.10. Table Partitioning I only saw the Range
> partition example throughout the Table Partitioning .
>
> I request you to modify the 5.10. Table Partitioning section and make it
> more informative as Table Partition is very important in PostgreSQL .

Well, there are examples in the CREATE TABLE manual page:

        https://www.postgresql.org/docs/12/sql-createtable.html

        When creating a hash partition, a modulus and remainder must be
        specified. The modulus must be a positive integer, and the remainder
        must be a non-negative integer less than the modulus. Typically, when
        initially setting up a hash-partitioned table, you should choose a
        modulus equal to the number of partitions and assign every table the
        same modulus and a different remainder (see examples, below). However,
        it is not required that every partition have the same modulus, only that
        every modulus which occurs among the partitions of a hash-partitioned
        table is a factor of the next larger modulus. This allows the number of
        partitions to be increased incrementally without needing to move all the
        data at once. For example, suppose you have a hash-partitioned table
        with 8 partitions, each of which has modulus 8, but find it necessary to
        increase the number of partitions to 16. You can detach one of the
        modulus-8 partitions, create two new modulus-16 partitions covering the
        same portion of the key space (one with a remainder equal to the
        remainder of the detached partition, and the other with a remainder
        equal to that value plus 8), and repopulate them with data. You can then
        repeat this -- perhaps at a later time -- for each modulus-8 partition
        until none remain. While this may still involve a large amount of data
        movement at each step, it is still better than having to create a whole
        new table and move all the data at once.

        CREATE TABLE orders (
            order_id     bigint not null,
            cust_id      bigint not null,
            status       text
        ) PARTITION BY HASH (order_id);

        CREATE TABLE orders_p1 PARTITION OF orders
            FOR VALUES WITH (MODULUS 4, REMAINDER 0);
        CREATE TABLE orders_p2 PARTITION OF orders
            FOR VALUES WITH (MODULUS 4, REMAINDER 1);
        CREATE TABLE orders_p3 PARTITION OF orders
            FOR VALUES WITH (MODULUS 4, REMAINDER 2);
        CREATE TABLE orders_p4 PARTITION OF orders
            FOR VALUES WITH (MODULUS 4, REMAINDER 3);


        CREATE TABLE cities (
            city_id      bigserial not null,
            name         text not null,
            population   bigint
        ) PARTITION BY LIST (left(lower(name), 1));

        CREATE TABLE cities_ab
            PARTITION OF cities (
            CONSTRAINT city_id_nonzero CHECK (city_id != 0)
        ) FOR VALUES IN ('a', 'b');

Is that sufficient?

--
  Bruce Momjian  <bruce@momjian.us>        https://momjian.us
  EnterpriseDB                             https://enterprisedb.com

+ As you are, so once was I.  As I am, so you will be. +
+                      Ancient Roman grave inscription +