> 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