Re: [HACKERS] Custom compression methods

On Wed, Mar 24, 2021 at 12:14 PM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> Actually, we are already doing this, I mean ALTER TABLE .. ALTER
> COLUMN .. SET COMPRESSION is already updating the compression method
> of the index attribute. So 0003 doesn't make sense, sorry for the
> noise. However, 0001 and 0002 are still valid, or do you think that
> we don't want 0001 also? If we don't need 0001 also then we need to
> update the test output for 0002 slightly.

It seems to me that 0002 is still not right. We can't fix the
attcompression to whatever the default is at the time the index is
created, because the default can be changed later, and there's no way
to fix index afterward. I mean, it would be fine to do it that way if
we were going to go with the other model, where the index state is
separate from the table state, either can be changed independently,
and it all gets dumped and restored. But, as it is, I think we should
be deciding how to compress new values for an expression column based
on the default_toast_compression setting at the time of compression,
not the time of index creation.

--
Robert Haas
EDB: http://www.enterprisedb.com