Re: [HACKERS] Custom compression methods

On Wed, Mar 24, 2021 at 10:57 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> 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.
>

Okay got it. Fixed as suggested.

--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com