Re: Index tuple deduplication limitations in pg13

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Matthias van de Meent <matthias(dot)vandemeent(at)cofano(dot)nl>
Cc: pgsql-general General <pgsql-general(at)postgresql(dot)org>
Subject: Re: Index tuple deduplication limitations in pg13
Date: 2020-08-18 16:44:08
Message-ID: CAH2-WzkZkSC7G+v1WwXGo0emh8E-rByw=xSpBUoavk7PTjwF2Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On Mon, Aug 17, 2020 at 11:44 PM Matthias van de Meent
<matthias(dot)vandemeent(at)cofano(dot)nl> wrote:
> But, if the ordering of operator-class equal tuples is already
> system-defined, could the physical ordering of index tuples in a btree
> (with deduplication enabled for "unsafe" opclasses) be updated from
> [index_columns, tid] to [index_columns,
> image_compare(non_datum_equal_columns), tid], giving a stable sorting
> of opclass-equal and image-equal values and enabling safe consistent
> deduplication?

The issue isn't the physical ordering. The issue is that we cannot
allow the implementation to destroy semantic differences among equal
datums. We avoid deduplication with cases where two equal datums are
visibly different. For example, it would not be okay if we forgot that
your numeric datum was originally input as '5.000', and output '5'
later on.

If we wanted to fix this for numeric, we'd have to invent a new
numeric datatype (called numeric2, say). That probably isn't as hard
as it sounds, since it could be part of the same B-Tree operator
family as numeric. It could also be implicitly cast to numeric.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Peter Geoghegan 2020-08-18 16:47:23 Re: Index tuple deduplication limitations in pg13
Previous Message David G. Johnston 2020-08-18 15:38:39 Re: import XML