Re: [HACKERS] Custom compression methods

On Wed, Mar 24, 2021 at 9:32 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>
> On Wed, Mar 24, 2021 at 11:41 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> > Okay, that sounds like a reasonable design idea. But the problem is
> > that in index_form_tuple we only have index tuple descriptor, not the
> > heap tuple descriptor. Maybe we will have to pass the heap tuple
> > descriptor as a parameter to index_form_tuple. I will think more
> > about this that how can we do that.
>
> Another option might be to decide that the pg_attribute tuples for the
> index columns always have to match the corresponding table columns.
> So, if you alter with ALTER TABLE, it runs around and updates all of
> the indexes to match. For expression index columns, we could store
> InvalidCompressionMethod, causing index_form_tuple() to substitute the
> run-time default. That kinda sucks, because it's a significant
> impediment to ever reducing the lock level for ALTER TABLE .. ALTER
> COLUMN .. SET COMPRESSION, but I'm not sure we have the luxury of
> worrying about that problem right now.

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.

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