Horton

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

Peter Geoghegan <pg@bowt.ie>

View thread View on postgr.es
From: Peter Geoghegan <pg@bowt.ie>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>
Date: 2019-08-25T21:29:36Z
Lists: pgsql-hackers 
On Sun, Aug 25, 2019 at 2:18 PM Peter Geoghegan <pg@bowt.ie> wrote:
> > Indeed, we run up against this sort of thing all the time in, eg, planner
> > optimizations.  I think some sort of "equality is precise" indicator
> > would be really useful for a lot of things.
>
> The case that I happened to think of was "collation strength
> reduction".

I was thinking of stashing an "equality is precise" flag in the
metapage of each nbtree index, since we will only determine this once,
at CREATE INDEX time. That would make it fairly natural for the
planner to ask about the "equality is precise"-ness of the index at
the same point that it calls _bt_getrootheight(): within
get_relation_info().

-- 
Peter Geoghegan

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.