Re: RFC: Moving specific attributes from pg_attribute column into attoptions

Hi hackers!

Tom, thank you for your feedback!
We thought about this because it already seems that custom Toasters
could have a bunch of options, so we already thinking how to store
them.

I'll check if we can implement storing Toaster options in PG_ATTRDEF.

Andres Freund complained that 'atttoaster' column extends already the
largest catalog table. It is a reasonable complain because atttoaster
option only makes sense for columns and datatypes only, and the
Default Toaster is accessible by global constant
DEFAULT_TOASTER_OID
and does not require accessing the PG_ATTRDEF table.

Also, we thought about making Toaster responsible for column compression
and thus moving 'attcompression' out from PG_ATTRIBUTE column to
Toaster options. What do you think about this?

Using JSON - accepted, we won't do it.

On Wed, Aug 17, 2022 at 11:51 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:

> Nikita Malakhov <hukutoc(at)gmail(dot)com> writes:
> > 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.
>
> This smells very much like what was done eons ago to create the
> pg_attrdef catalog. I don't have any concrete comments to make,
> only to suggest that that's an instructive parallel case. One
> thing that comes to mind immediately is whether this stuff could
> be unified with pg_attrdef instead of creating Yet Another catalog
> that has to be consulted on the way to getting any real work done.
>
> I think that pg_attrdef was originally separated to keep large
> default expressions from overrunning the maximum tuple size,
> a motivation that disappeared once we could TOAST system tables.
> However, nowadays it's still useful for it to be separate because
> it simplifies representation of dependencies of default expressions
> (pg_depend refers to OIDs of pg_attrdef entries for that).
> If we're thinking of moving anything that would need dependency
> management then it might need its own catalog, maybe?
>
> On the whole I'm not convinced that what you suggest will be a
> net win. pg_attrdef wins to the extent that there are a lot of
> columns with no non-null default and hence no need for any pg_attrdef
> entry. But the minute you move something that most tables need, like
> attcompression, you'll just have another bloated catalog to deal with.
>
> > Also, we suggest that options stored in 'attoptions' column could be
> packed
> > as JSON values.
>
> Please, no. Use of JSON in a SQL database pretty much always
> represents a failure to think hard enough about what you need
> to store. Sometimes it's not worth thinking all that hard;
> but I strenuously oppose applying that sort of standard in
> the system catalogs.
>
> regards, tom lane
>

--
Regards,
Nikita Malakhov
https://postgrespro.ru/