Re: On partitioning

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: On partitioning
Дата
Msg-id CA+TgmoZOE2KmrNSSk8y9oR-9HpYzvbVmBzwrb33r9yKKnogysg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: On partitioning  ("Amit Langote" <Langote_Amit_f8@lab.ntt.co.jp>)
Список pgsql-hackers
On Mon, Dec 8, 2014 at 12:13 AM, Amit Langote
<Langote_Amit_f8@lab.ntt.co.jp> wrote:
> So just to clarify, first and last destinations are considered "defined" if you have something like:
>
> ...
> PARTITION p1 VALUES LESS THAN 10
> PARTITION p2 VALUES BETWEEN 10 AND 20
> PARTITION p3 VALUES GREATER THAN 20
> ...
>
> And "not defined" if:
>
> ...
> PARTITION p1 VALUES BETWEEN 10 AND 20
> ...

Yes.

>> For pg_dump --binary-upgrade, you need a statement like SELECT
>> binary_upgrade.set_next_toast_pg_class_oid('%d'::pg_catalog.oid) for
>> each pg_class entry.  So you can't easily have a single SQL statement
>> creating multiple such entries.
>
> Hmm, do you mean "pg_dump cannot emit" such a SQL or there shouldn't be one in the first place?

I mean that the binary upgrade script needs to set the OID for every
pg_class object being restored, and it does that by stashing away up
to one (1) pg_class OID before each CREATE statement.  If a single
CREATE statement generates multiple pg_class entries, this method
doesn't work.

> Makes sense. This would double as a way to create subpartitions too? And that would have to play well with any choice
weend up making about how we treat subpartitioning key (one of the points discussed above)
 

Yes, I think so.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: On partitioning
Следующее
От: Robert Haas
Дата:
Сообщение: Re: On partitioning