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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: FK's to refer to rows in inheritance child
Дата
Msg-id A5014CC4-D5BA-4105-BCD0-1AF5C241BBCB@gmail.com
обсуждение исходный текст
Ответ на Re: FK's to refer to rows in inheritance child  (Dimitri Fontaine <dimitri@2ndQuadrant.fr>)
Ответы Re: FK's to refer to rows in inheritance child  (Andrew Dunstan <andrew@dunslane.net>)
Список pgsql-hackers
On Dec 4, 2010, at 1:22 PM, Dimitri Fontaine <dimitri@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
tospeculate about whether it'd be useful here. What is needed right now is design work, not code. 

...Robert

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: SQL/MED - file_fdw
Следующее
От: Jeff Janes
Дата:
Сообщение: Re: profiling connection overhead