| 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:47:23 |
| Message-ID: | CAH2-WznkxRdhzqBsgf=L34vp2bpzxeG0SC8JYiwp1DFMOAhRRA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
On Tue, Aug 18, 2020 at 9:44 AM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> 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.
I forgot to say: numeric2 would be just like numeric, except in one
specific way: it wouldn't care about display scale. The user would be
giving up on display scale by choosing numeric2 over numeric. The "5
vs 5.000" information would always be lost by design, so there'd be
nothing for deduplication to break. Deduplication could then be
enabled.
--
Peter Geoghegan
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Scottix | 2020-08-18 18:05:22 | Re: "Go" (lang) standard driver |
| Previous Message | Peter Geoghegan | 2020-08-18 16:44:08 | Re: Index tuple deduplication limitations in pg13 |