Andres Freund <and...@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) 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. I'm willing to live with that, especially since that's *before* compression. (Your example does not show that compression was ineffective; more likely it wasn't tried, since the pg_class tuple was under 2K.) The LIST case might be more of a problem, but I'm not sure. It looks like that eats circa 150 bytes per value in outfuncs.c format, but they're *very* repetitive and compress really well. I get about 16 stored bytes per value with a long list of integer keys, so it looks like you could approach 500 values in the LIST before hitting trouble. Maybe a few less with wider datatypes. 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. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers