Re: FK's to refer to rows in inheritance child

On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)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