Tom Lane <t...@sss.pgh.pa.us> writes: > partitioning. I have a feeling that the feature will languish on the > TODO list forever, unless someone comes up with a brilliant idea to > avoid the problems. As is, the return on investment to do it just > isn't there.
That's calling for a try :) What about a new index type that follows the partitioning scheme in its root pages in a way that allow the locking to occur in a subpart of it, rather than for the whole index. Well, maybe that needs to have an index OID per known partition all handled into the same physical index for the locking system to work, but that could mean that indexes would get their objsubid like relations have their attributes now. It could even be that what we need is a meta-index and a new kind if index page pointer that would lead to another physical index. Oh and that's yet another idea that depends on seeing a partition syntax supporting current features in core. When will we sketch a plan on that so that individual hackers interested into a subpart are able to work on it? I think the last years are telling us that nobody will ever will to handle it all by himself. Well, or you have to hire Simon :) Given such an agenda, I'd argue for a feature branch being open for partitioning so that incremental reviewed work can happen there until we have enough pieces to consider merging into HEAD. Regards, -- Dimitri Fontaine http://2ndQuadrant.fr PostgreSQL : Expertise, Formation et Support -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers