Horton

Re: Declarative partitioning - another take

Robert Eckhardt <reckhardt@pivotal.io>

View thread View on postgr.es
From: Robert Eckhardt <reckhardt@pivotal.io>
To: Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>
Cc: Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Robert Haas <robertmhaas@gmail.com>, Pg Hackers <pgsql-hackers@postgresql.org>
Date: 2016-08-16T14:05:21Z
Lists: pgsql-hackers 
On Tue, Aug 16, 2016 at 2:30 AM, Ashutosh Bapat <
ashutosh.bapat@enterprisedb.com> wrote:

>
>
>
>
>> I think it makes sense to keep calling it a table because it has all the
>> logical properties of a table even though it will differ from a regular
>> table on the basis of physical implementation details such as that it does
>> not own physical storage.  Am I missing something?
>>
>> >
>> > +      <entry><structfield>partexprs</structfield></entry>
>> >
>> > There's a certain symmetry between this and what we do for indexes,
>> > but I'm wondering whether there's a use case for partitioning a table
>> > by an expression rather than a column value.  I suppose if you've
>> > already done the work, there's no harm in supporting it.
>>
>> Yeah, it's not a whole lot of code to manage expressions alongside simple
>> column references.
>>
>
> Users who would like to partition their tables by "age" will partition
> those by the month or year extracted out of a date column e.g. order_date.
> They will find it convenient to use an expression (extract(month from
> date)) as a partition key, instead of storing month or year as a separate
> column.
>

In GPDB we have partitioning. It is almost always by date and then often
the partitions are for different sizes, i.e. by day for 30 days then by
month for 3 years then by year. What we also support, but isn't super
performant, is sub-partitioning.

This is where some on the newer indexing strategies is interesting to me. I
see them as synergistic not redundant.


>
> --
> Best Wishes,
> Ashutosh Bapat
> EnterpriseDB Corporation
> The Postgres Database Company
>

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.