From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dimitri Fontaine <dimitri(at)2ndQuadrant(dot)fr> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Greg Stark <gsstark(at)mit(dot)edu>, YebHavinga <yebhavinga(at)gmail(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>, "w(dot)p(dot)dijkstra(at)mgrid(dot)net" <w(dot)p(dot)dijkstra(at)mgrid(dot)net> |
Subject: | Re: FK's to refer to rows in inheritance child |
Date: | 2010-12-05 00:12:49 |
Message-ID: | A5014CC4-D5BA-4105-BCD0-1AF5C241BBCB@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Jeff Janes | 2010-12-05 01:04:43 | Re: profiling connection overhead |
Previous Message | Andrew Dunstan | 2010-12-04 22:24:36 | Re: SQL/MED - file_fdw |