On Tue, Mar 16, 2021 at 11:18 AM Justin Pryzby <pry...@telsasoft.com> wrote: > > I'm a minor contributor now to a couple bits of this patch set, but I can > answer a couple of these points. > > On Mon, Mar 15, 2021 at 03:58:35PM -0700, Andres Freund wrote: > > Comments about 0003: > > - why is HIDE_TOAST_COMPRESSION useful? Doesn't quite seem to be > > comparable to HIDE_TABLEAM? > > That was my idea and implementation. > It's because until 3 weeks ago, the patchset supported a "plugable compression > API" like CREATE ACCESS METHOD, a suggestion from Alvaro to avoid making a new > table and everything involved just for a few rows). Now, the patch is limited > to lz4, and the "pluggable compression APIs" isn't included in the latest > patchsets.
Yeah, but now also it makes sense to hide the compression method to avoid unrelated regression changes. But I am okay if we think we want to drop this? > > Comments about 0005: > > - I'm personally not really convinced tracking the compression type in > > pg_attribute the way you do is really worth it (. Especially given > > that it's right now only about new rows anyway. Seems like it'd be > > easier to just treat it as a default for new rows, and dispense with > > all the logic around mismatching compression types etc? > > I made the half-serious suggestion to make it a per-relation relopt. > That would allow implementing pg_dump --no-toast-compression, to allow > restoring a dump from a server with LZ4 tables to a server --without-lz4. > Similar to --no-tablespaces. I am not sure how good an idea it is to support table-level options. The attribute level option makes sense to me in case we want to support different compression methods for different data types. Currently, we have only pglz and lz4 but if we are not planning for custom compression in the future then we can support 2 more built-in compression methods so I still feel having an attribute level option makes more sense. -- Regards, Dilip Kumar EnterpriseDB: http://www.enterprisedb.com
