On Thu, Nov 6, 2014 at 9:17 PM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> I mentioned upthread about the possibility of resurrecting Itagaki-san's patch [1] to try to make things work in
thisdirection. I would be willing to spend time on this. I see useful reviews of the patch by Robert [2], Simon [3] at
thetime but it wasn't pursued further. I think those reviews were valuable design input that IMHO would still be
relevant.It seems the reviews suggested some significant changes to the design proposed. Off course, there are many
otherconsiderations discussed upthread that need to be addressed. Incorporating those changes and others, I think such
anapproach could be worthwhile.
I'd be in favor of that. I am not sure whether the code is close
enough to what we need to be really useful, but that's for you to
decide. In my view, the main problem we should be trying to solve
here is "avoid relying on constraint exclusion". In other words, the
syntax for adding a partition should put some metadata into the system
catalogs that lets us do partitioning pruning very very quickly,
without theorem-proving. For example, for list or range partitioning,
a list of partition bounds would be just right: you could
binary-search it. The same metadata should also be suitable for
routing inserts to the proper partition, and handling partition motion
when a tuple is updated.
Now there's other stuff we might very well want to do, but I think
making partition pruning and tuple routing fast would be a pretty big
win by itself.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company