Re: [PATCH] Automatic HASH and LIST partition creation

Поиск
Список
Период
Сортировка
От Fabien COELHO
Тема Re: [PATCH] Automatic HASH and LIST partition creation
Дата
Msg-id alpine.DEB.2.22.394.2012230937140.533489@pseudo
обсуждение исходный текст
Ответ на Re: [PATCH] Automatic HASH and LIST partition creation  (Pavel Borisov <pashkin.elfe@gmail.com>)
Ответы Re: [PATCH] Automatic HASH and LIST partition creation  (Pavel Borisov <pashkin.elfe@gmail.com>)
Список pgsql-hackers
> Fabien, do you consider it possible to change the syntax of declarative
> partitioning too?

My 0.02 €: What I think does not matter much, what committers think is the 
way to pass something. However, I do not think that such an idea would 
pass a committer:-)

> It is problematic as it is already committed but also is very tempting 
> to have the same type of syntax both in automatic partitioning and in 
> manual (PARTITION OF...)

I think that if a "common" syntax, for a given meaning of common, can be 
thought of, and without breaking backward compatibility, then there may be 
an argument to provide such a syntax, but I would not put too much energy 
into that if I were you.

I see 3 cases:

  - partition declaration but no actual table generated, the current
    version.

  - partition declaration with actual sub-tables generated, eg for hash
    where it is pretty straightforward to know what would be needed, or for
    a bounded range.

  - partition declaration without generated table, but they are generated
    on demand, when needed, for a range one may want weekly or monthly
    without creating tables in advance, esp. if it is unbounded.

ISTM that the syntax should be clear and if possible homogeneous for all 
three use cases, even if they are not implemented yet. It should also 
allow easy extensibility, hence something without a strong syntax, 
key/value pairs to be interpreted later.

-- 
Fabien.

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

Предыдущее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Fail Fast In CTAS/CMV If Relation Already Exists To Avoid Unnecessary Rewrite, Planning Costs
Следующее
От: "tsunakawa.takay@fujitsu.com"
Дата:
Сообщение: RE: [Patch] Optimize dropping of relation buffers using dlist