Horton

Re: Declarative partitioning - another take

Alexander Korotkov <a.korotkov@postgrespro.ru>

View thread View on postgr.es
From: Alexander Korotkov <a.korotkov@postgrespro.ru>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Dmitry Ivanov <d.ivanov@postgrespro.ru>, Michael Paquier <michael.paquier@gmail.com>, Andres Freund <andres@anarazel.de>, Erik Rijkers <er@xs4all.nl>, Amit Langote <amitlangote09@gmail.com>, Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>, Rajkumar Raghuwanshi <rajkumar.raghuwanshi@enterprisedb.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Pg Hackers <pgsql-hackers@postgresql.org>, pgsql-hackers-owner@postgresql.org
Date: 2016-12-08T16:43:09Z
Lists: pgsql-hackers 
On Thu, Dec 8, 2016 at 7:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:

> On Thu, Dec 8, 2016 at 11:13 AM, Dmitry Ivanov <d.ivanov@postgrespro.ru>
> wrote:
> > We (PostgresPro) have been working on pg_pathman for quite a while, and
> > since it's obviously going to become the thing of the past, it would be a
> > wasted effort if we didn't try to participate.
> >
> > For starters, I'd love to work on both plan-time & run-time partition
> > pruning. I created a custom node for run-time partition elimination, so I
> > think I'm capable of developing something similar.

That would be fantastic.  I and my colleagues at EnterpriseDB can
> surely help review;


Great! And it is very cool that we have basic infrastructure already
committed.  Thanks a lot to you and everybody involved.


> of course, maybe you and some of your colleagues
> would like to help review our patches, too.


We understand our reviewing performance is not sufficient.  Will try to do
better during next commitfest.


> Do you think this is
> likely to be something where you can get something done quickly, with
> the hope of getting it into v10?


Yes, because we have set of features already implemented in pg_pathman.  In
particular we have following features from your list and some more.

- more efficient plan-time partition pruning (constraint exclusion is too
slow)
- run-time partition pruning
- insert (and eventually update) tuple routing for foreign partitions
- hash partitioning
- not scanning the parent

Time is growing short, but it would
> be great to polish this a little more before we ship it.
>

Yes. Getting at least some of this features committed to v10 would be great
and improve partitioning usability a lot.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres 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.