Re: [HACKERS] Relpartbound, toasting and pg_class
От | Andres Freund |
---|---|
Тема | Re: [HACKERS] Relpartbound, toasting and pg_class |
Дата | |
Msg-id | 20170612231734.rbsdc6eaecnf6vqh@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: [HACKERS] Relpartbound, toasting and pg_class (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [HACKERS] Relpartbound, toasting and pg_class
|
Список | pgsql-hackers |
On 2017-06-12 19:00:02 -0400, Tom Lane wrote: > Andres Freund <andres@anarazel.de> writes: > > On 2017-06-12 18:10:52 -0400, Tom Lane wrote: > >> it'd be worthwhile checking some actual examples rather than guessing. > > > It's indeed not very compact. E.g a simple example with small types: > > > CREATE TABLE partitioned(a int, b int, c timestamptz, data text) PARTITION BY RANGE (a, b, c); > > CREATE TABLE partitioned_child1 PARTITION OF partitioned FOR VALUES FROM (1, 1, '2017-01-01') TO (1, 1, '2017-02-01'); > > > postgres[6961][1]=# SELECT relname, pg_column_size(relpartbound), length(relpartbound), pg_column_size(pg_class) FROMpg_class WHERE relpartbound IS NOT NULL; > > ┌───────────────────────────────┬────────────────┬────────┬────────────────┐ > > │ relname │ pg_column_size │ length │ pg_column_size │ > > ├───────────────────────────────┼────────────────┼────────┼────────────────┤ > > │ partitioned_child1 │ 1355 │ 1351 │ 1523 │ > > │ partitioneded_list_committers │ 1130 │ 8049 │ 1298 │ > > └───────────────────────────────┴────────────────┴────────┴────────────────┘ > > So, counting on my fingers, you'd need something like twenty partitioning > columns before you hit trouble with the RANGE syntax. Well, that's with 4/8 byte wide types. I'd be surprised if people only ever used those. I'd bet quite a bit that people will start using jsonb, postgis' geometry and such as partition types, even if it makes most of us cringe. > On the whole, I'm inclined to agree with Peter and Alvaro that this is > fine, at least for the short term. Even in the long term, I doubt we > need toastability, just a more compact representation than an expression > tree. bytea storage of an array, perhaps? Or maybe better, use anyarray > like we do in pg_statistic, so that it prints legibly. I'm not quite sure where the aversion to adding a toast table to pg_class is coming from? Why are we ok with arbitrary and hard to understand restrictions here, and not elsewhere? Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: