On Thu, Nov 6, 2014 at 9:17 PM, Amit Langote <langote_amit...@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 this direction. I would be willing to > spend time on this. I see useful reviews of the patch by Robert [2], Simon > [3] at the time 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 other considerations discussed upthread that need to be addressed. > Incorporating those changes and others, I think such an approach 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
