Re: [HACKERS] Custom compression methods

On 2021-Mar-19, Robert Haas wrote:

> > Regarding your point, that does look like clutter. We don't annotate
> > the dump with a storage clause unless it's non-default, so probably we
> > should do the same thing here. I think I gave Dilip bad advice here...
>
> Here's a patch for that. It's a little strange because you're going to
> skip dumping the toast compression based on the default value on the
> source system, but that might not be the default on the system where
> the dump is being restored, so you could fail to recreate the state
> you had. That is avoidable if you understand how things work, but some
> people might not. I don't have a better idea, though, so let me know
> what you think of this.

Do you mean the column storage strategy, attstorage? I don't think
that's really related, because the difference there is not a GUC setting
but a compiled-in default for the type. In the case of compression, I'm
not sure it makes sense to do it like that, but I can see the clutter
argument: if we dump compression for all columns, it's going to be super
noisy.

(At least, for binary upgrade surely you must make sure to apply the
correct setting regardless of defaults on either system).

Maybe it makes sense to dump the compression clause if it is different
from pglz, regardless of the default on the source server. Then, if the
target server has chosen lz4 as default, *all* columns are going to end
up as lz4, and if it hasn't, then only the ones that were lz4 in the
source server are going to. That seems reasonable behavior. Also, if
some columns are lz4 in source, and target does not have lz4, then
everything is going to work out to not-lz4 with just a bunch of errors
in the output.

--
Álvaro Herrera 39°49'30"S 73°17'W