Ildus Kurbangaliev wrote: > If the table is big, decompression could take an eternity. That's why i > decided to only to disable it and the data could be decompressed using > compression options. > > My idea was to keep compression options forever, since there will not > be much of them in one database. Still that requires that extension is > not removed. > > I will try to find a way how to recompress data first in case it moves > to another table.
I think what you should do is add a dependency between a column that compresses using a method, and that method. So the method cannot be dropped and leave compressed data behind. Since the method is part of the extension, the extension cannot be dropped either. If you ALTER the column so that it uses another compression method, then the table is rewritten and the dependency is removed; once you do that for all the columns that use the compression method, the compression method can be dropped. Maybe our dependency code needs to be extended in order to support this. I think the current logic would drop the column if you were to do "DROP COMPRESSION .. CASCADE", but I'm not sure we'd see that as a feature. I'd rather have DROP COMPRESSION always fail instead until no columns use it. Let's hear other's opinions on this bit though. -- Álvaro Herrera https://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
