On Thu, Feb 20, 2020 at 7:38 AM Anastasia Lubennikova <a.lubennik...@postgrespro.ru> wrote: > I don't think this patch really needs more nitpicking )
But when has that ever stopped it? :-) > User can discover this with a complex query to pg_index and pg_opclass. > To simplify this, we can probably wrap this into function or some field > in pg_indexes. A function isn't a real user interface, though -- it probably won't be noticed. I think that there is a good chance that it just won't matter. The number of indexes that won't be able to support deduplication will be very small in practice. The important exceptions are INCLUDE indexes and nondeterministic collations. These exceptions make sense intuitively, and will be documented as limitations of those other features. The numeric/float thing doesn't really make intuitive sense, and numeric is an important datatype. Still, numeric columns and float columns seem to rarely get indexed. That just leaves container type opclasses, like anyarray and jsonb. Nobody cares about indexing container types with a B-Tree index, with the possible exception of expression indexes on a jsonb column. I don't see a way around that, but it doesn't seem all that important. Again, applications are unlikely to have more than one or two of those. The *overall* space saving will probably be almost as good as if the limitation did not exist. > Anyway, I would wait for feedback from pre-release testers. Right -- let's delay making a final decision on it. Just like the decision to enable it by default. It will work this way in the committed version, but that isn't supposed to be the final word on it. -- Peter Geoghegan
