Re: Partitioning: issues/ideas (Was: Re: On partitioning)

Поиск
Список
Период
Сортировка
От Amit Langote
Тема Re: Partitioning: issues/ideas (Was: Re: On partitioning)
Дата
Msg-id 54C59BA1.9010509@lab.ntt.co.jp
обсуждение исходный текст
Ответ на Re: Partitioning: issues/ideas (Was: Re: On partitioning)  (Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Ответы Re: Partitioning: issues/ideas (Was: Re: On partitioning)  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Список pgsql-hackers
On 21-01-2015 PM 07:26, Amit Langote wrote:
> Ok, I will limit myself to focusing on following things at the moment:
> 
> * Provide syntax in CREATE TABLE to declare partition key

While working on this, I stumbled upon the question of how we deal with
any index definitions following from constraints defined in a CREATE
statement. I think we do not want to have a physical index created for a
table that is partitioned (in other words, has no heap of itself). As
the current mechanisms dictate, constraints like PRIMARY KEY, UNIQUE,
EXCLUSION CONSTRAINT are enforced as indexes. It seems there are really
two decisions to make here:

1) how do we deal with any index definitions (either explicit or
implicit following from constraints defined on it) - do we allow them by
marking them specially, say, in pg_index, as being mere
placeholders/templates or invent some other mechanism?

2) As a short-term solution, do we simply reject creating any indexes
(/any constraints that require them) on a table whose definition also
includes PARTITION ON clause? Instead define them on its partitions (or
any relations in hierarchy that are not further partitioned).

Or maybe I'm missing something...

Thanks,
Amit




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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: longjmp clobber warnings are utterly broken in modern gcc
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: Error check always bypassed in tablefunc.c