| From: | Bruce Momjian <bruce(at)momjian(dot)us> |
|---|---|
| To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
| Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: PG 13 release notes, first draft |
| Date: | 2020-05-12 01:23:30 |
| Message-ID: | 20200512012330.GS4666@momjian.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, May 11, 2020 at 09:15:43PM -0400, Bruce Momjian wrote:
> On Mon, May 11, 2020 at 05:33:40PM -0700, Peter Geoghegan wrote:
> > On Mon, May 11, 2020 at 5:14 PM Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > > Agreed. How is this?
> > >
> > > This allows efficient btree indexing of low cardinality columns.
> > > Users upgrading with pg_upgrade will need to use REINDEX to make use of
> > > this feature.
> >
> > I still think that the release notes should say that the key is only
> > stored once, while TIDs that identify table rows are stored together
> > as an array. Everything that's helpful (or harmful) about the feature
> > happens as a consequence of that. This isn't hard to grasp
> > intuitively, and is totally in line with how things like Oracle bitmap
> > indexes are presented to ordinary users.
>
> I still don't think these details belong in the release notes.
OK, I was able to add some of it cleanly:
This allows efficient btree indexing of low cardinality columns by
storing duplicate keys only once. Users upgrading with pg_upgrade
will need to use REINDEX to make use of this feature.
--
Bruce Momjian <bruce(at)momjian(dot)us> https://momjian.us
EnterpriseDB https://enterprisedb.com
+ As you are, so once was I. As I am, so you will be. +
+ Ancient Roman grave inscription +
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Amit Langote | 2020-05-12 01:28:56 | Re: PG 13 release notes, first draft |
| Previous Message | Bruce Momjian | 2020-05-12 01:15:43 | Re: PG 13 release notes, first draft |