On Wed, Dec 16, 2020 at 5:28 PM Justin Pryzby <pry...@telsasoft.com> wrote: > Even though the message literally says whether the index "can safely" or > "cannot" use deduplication, the function specifically avoids the debug message > for system columns, so I think it also makes sense to hide it when > deduplication is turned off.
I disagree. The point of the message is to advertise whether deduplication is possible in principle for indexes where support is not precluded by a significant design issue that will almost certainly not change in the future. The debug message should only apply to indexes without INCLUDE non-key columns that are not system catalog indexes. In general, I think of the storage parameter as advisory. If it wasn't advisory then we'd have no way of rescinding support for deduplication in the event of an opclass that somehow gets the "equality implies image equality" question wrong. If it wasn't advisory then we might end up raising an error when the user explicitly asks for deduplication but that isn't possible -- which might break somebody's pg_restore workflow. Even when deduplication is both the safe and the desired behavior, there is at least one case where it's applied selectively. We do this in unique indexes, where deduplication can only help with version churn duplicates and so we only try to deduplicate when that appears to be a factor. By the same token, when the user disables deduplication via the storage parameter (presumably due to the performance trade-off somehow not seeming useful), they cannot expect to get back to an on-disk representation without posting list tuples, unless and until they REINDEX. -- Peter Geoghegan
