From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Relpartbound, toasting and pg_class |
Date: | 2017-06-12 23:17:34 |
Message-ID: | 20170612231734.rbsdc6eaecnf6vqh@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2017-06-12 19:00:02 -0400, Tom Lane wrote:
> Andres Freund <andres(at)anarazel(dot)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) FROM pg_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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2017-06-12 23:19:34 | Re: Relpartbound, toasting and pg_class |
Previous Message | Tom Lane | 2017-06-12 23:00:02 | Re: Relpartbound, toasting and pg_class |