RFC: Moving specific attributes from pg_attribute column into attoptions - Mailing list pgsql-hackers

From Nikita Malakhov
Subject RFC: Moving specific attributes from pg_attribute column into attoptions
Date
Msg-id CAN-LCVOLJQCE0EKp8-ZU6zRz+nEfr3Pe99-iUptNh+wSfR5a6w@mail.gmail.com
Whole thread Raw
Responses Re: RFC: Moving specific attributes from pg_attribute column into attoptions
List pgsql-hackers
Hi hackers!

While working on Pluggable TOAST we extended the PG_ATTRIBUTE table with a new 
column 'atttoaster'. But is is obvious that this column is related to tables, columns and datatypes 
only, and is not needed for other attributes.
You can find full discussion on Pluggable TOAST here

We already had some thoughts on storing, let's call them "optional" attributes into 'attoptions'
instead of extending the PG_ATTRIBUTE table, and here came feedback from Andres Freund
with a remark that we're increasing the largest catalog table. So we decided to propose moving 
these "optional" attributes from being the PG_ATTRIBUTE column to be the part of 'attoptions' 
column of this table. 
The first most suspected attributes to store in attoptions column are the 'atttoaster' and 
'attcompression', because they are related to datatypes and table columns. Also, this change
will allow setting options for custom Toasters, which makes a lot of sense too, according with
an important [as we see it] 'force TOAST' option which is meant to force given value to be
TOASTed bypassing existing logic (reference depends on tuple and value size).

Also, we suggest that options stored in 'attoptions' column could be packed as JSON values.

It seems to make a lot of sense to optimize PG_ATTRIBUTE structure and size with attributes 
related only to specific types, etc.

We'd welcome any opinions, suggestions and advice!

--
Regards,
Nikita Malakhov

pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: cataloguing NOT NULL constraints
Next
From: Alvaro Herrera
Date:
Subject: Re: cataloguing NOT NULL constraints