Horton

Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence

Alvaro Herrera <alvherre@2ndquadrant.com>

View thread View on postgr.es
From: Alvaro Herrera <alvherre@2ndquadrant.com>
To: Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Cc: Antonin Houska <ah@cybertec.at>, Peter Geoghegan <pg@bowt.ie>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-12-24T16:08:29Z
Lists: pgsql-hackers 
> @@ -106,6 +106,18 @@ CREATE OPERATOR CLASS <replaceable class="parameter">name</replaceable> [ DEFAUL
>      </listitem>
>     </varlistentry>
>  
> +    <varlistentry>
> +    <term><literal>NOT BITWISE</literal></term>
> +    <listitem>
> +     <para>
> +      If present, the operator class equality is not the same as equivalence.
> +      For example, two numerics can compare equal but have different scales.
> +      Most opclasses implement bitwise equal comparison, alternative behaviour
> +      must be set explicitly.
> +     </para>
> +    </listitem>
> +   </varlistentry>

Am I the only one bothered by the fact that this patch (and all
downstream discussion) reduces the term "bitwise equality" to simply
"bitwise"?  It reads really strange to me, both in the resulting SQL
grammar as well as in struct names, code comments etc.  "This operator
class is bitwise."

-- 
Álvaro Herrera                https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Add equalimage B-Tree support functions.

  2. Make _bt_keep_natts_fast() use datum_image_eq().

  3. Teach datum_image_eq() about cstring datums.

  4. Fix optimization of foreign-key on update actions

  5. Support all SQL:2011 options for window frame clauses.

  6. Create a "sort support" interface API for faster sorting.