Re: Declarative partitioning - another take

Amit Langote <langote_amit_f8@lab.ntt.co.jp>

From: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>
To: Amit Langote <amitlangote09@gmail.com>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>
Cc: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-09T08:55:48Z
Lists: pgsql-hackers

Attachments

On 2016/09/06 22:04, Amit Langote wrote:
> Will fix.

Here is an updated set of patches.

In addition to fixing a couple of bugs reported by Ashutosh and Rajkumar,
there are a few of major changes:

* change the way individual partition bounds are represented internally
  and the way a collection of partition bounds associated with a
  partitioned table is exposed to other modules.  Especially list
  partition bounds which are manipulated more efficiently as discussed
  at [1].

* \d partitioned_table now shows partition count and \d+ lists partition
  names and their bounds as follows:

\d t6
           Table "public.t6"
 Column |       Type        | Modifiers
.-------+-------------------+-----------
 a      | integer           |
 b      | character varying |
Partition Key: LIST (a)
Number of partitions: 3 (Use \d+ to list them.)

\d+ t6
                               Table "public.t6"
 Column |       Type        | Modifiers | Storage  | Stats target |
Description
.-------+-------------------+-----------+----------+--------------+-------------
 a      | integer           |           | plain    |              |
 b      | character varying |           | extended |              |
Partition Key: LIST (a)
Partitions: t6_p1 FOR VALUES IN (1, 2, NULL),
            t6_p2 FOR VALUES IN (4, 5),
            t6_p3 FOR VALUES IN (3, 6)

\d+ p
                             Table "public.p"
 Column |     Type     | Modifiers | Storage  | Stats target | Description
.-------+--------------+-----------+----------+--------------+-------------
 a      | integer      |           | plain    |              |
 b      | character(1) |           | extended |              |
Partition Key: RANGE (a)
Partitions: p1 FOR VALUES START (1) END (10),
            p2 FOR VALUES START (10) END (20),
            p3 FOR VALUES START (20) END (30),
            p4 FOR VALUES START (30) EXCLUSIVE END (40) INCLUSIVE,
            p5 FOR VALUES START (40) EXCLUSIVE END (50),
            p6 FOR VALUES START (50) END UNBOUNDED

* Some more regression tests

Thanks,
Amit

[1]
https://www.postgresql.org/message-id/CA%2BTgmoZCr0-t93KgJA3T1uy9yWxfYaSYL3X35ObyHg%2BZUfERqQ%40mail.gmail.com

Commits

  1. Fix typo.

  2. Document trigger-firing behavior for inheritance/partitioning.

  3. Fire per-statement triggers on partitioned tables.

  4. Set ecxt_scantuple correctly for tuple routing.

  5. Fix interaction of partitioned tables with BulkInsertState.

  6. Avoid core dump for empty prepared statement in an aborted transaction.

  7. Fix some problems in check_new_partition_bound().

  8. Remove unnecessary arguments from partitioning functions.

  9. Fix reporting of constraint violations for table partitioning.

  10. Fix tuple routing in cases where tuple descriptors don't match.

  11. Invalid parent's relcache after CREATE TABLE .. PARTITION OF.

  12. Doc: improve documentation about inheritance.