Re: Declarative partitioning

From: Alexander Korotkov <a(dot)korotkov(at)postgrespro(dot)ru>
To: Amit Langote <amitlangote09(at)gmail(dot)com>
Cc: Amit Langote <Langote_Amit_f8(at)lab(dot)ntt(dot)co(dot)jp>, Corey Huinker <corey(dot)huinker(at)gmail(dot)com>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Declarative partitioning
Date: 2016-03-16 14:49:52
Message-ID: CAPpHfdu0mGbt9T2Jx04OKJfJQ0zW55BFqmisinRYWd2OaowRWQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 16, 2016 at 5:29 PM, Amit Langote <amitlangote09(at)gmail(dot)com>
wrote:

> > 9.6 feature freeze in coming, and we're planning our development
> resources
> > for 9.7. Besides providing an extension, we would like these features to
> > eventually arrive to core. In order to achieve this we need to port out
> > functionality over your declarative syntax. At first, we would need some
> > way for caching partition metadata suitable for fast partition selection.
> > For range partition it could be sorted array or RB-tree of partition
> bounds.
> > When we have this infrastructure, we can start porting pieces of
> pg_pathman
> > functionality to declarative partitiong.
>
> I had to think about the internal metadata representation (and its
> caching) when developing the tuple routing solution. I am hopeful
> that it is suitable for other executor mechanisms we will build for
> partitioned tables.
>

Yes, it appears that I missed it. You already have sorted array for range
partitioning and binary search implementation. This is good.
I'm a bit worrying about list partitioning because in this case you scan
array sequentially. We could optimize this case for better handling of
many list partitions. This is probably not most common case though.

> So, our draft plan of patches would be following:
> >
> > Implement partition metadata cache suitable for fast partition selection.
> > Fast partition selection using metadata cache.
> > Optimization of filter conditions passed to partitions.
> > Execute time partitions selection (useful for nested loops and prepared
> > statements);
> > Optimization of ordered output from patitioned tables (use Append
> instead of
> > MergeAppend when possible);
> > Optimization of hash join when both tables are patitioned by join key.
> >
> > I'd like to validate that this development plan doesn't overlaps with
> your
> > plans. If out plans are not overlapping then let's accept this plan of
> work
> > for 9.7.
>
> It looks OK to me. Thanks for sharing it.
>

Great! Let's work together.

------
Alexander Korotkov
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Aleksander Alekseev 2016-03-16 15:11:04 Small patch: fix comments in contrib/pg_trgm/
Previous Message Robert Haas 2016-03-16 14:47:00 Re: Parallel Aggregate