| From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru> |
| Subject: | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |
| Date: | 2019-08-25 21:29:36 |
| Message-ID: | CAH2-WzkWR2LSLNVpVq2XJbF1kjPP97PX6LCW=xPAd0X2Rnutow@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Sun, Aug 25, 2019 at 2:18 PM Peter Geoghegan <pg(at)bowt(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2019-08-25 21:40:04 | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |
| Previous Message | Peter Geoghegan | 2019-08-25 21:18:12 | Re: Building infrastructure for B-Tree deduplication that recognizes when opclass equality is also equivalence |