On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine <dimi...@2ndquadrant.fr> > 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.
Surely the top-level structure here needs to be organized by key, not partition; else it's no better than an index per partition. > 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. I wouldn't necessarily be opposed to official topic branches at some point in the future, but I think it's premature to speculate about whether it'd be useful here. What is needed right now is design work, not code. ...Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
