From: | Peter Geoghegan <pg(at)bowt(dot)ie> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: can system catalogs have GIN indexes? |
Date: | 2023-04-27 18:17:17 |
Message-ID: | CAH2-WzkRgMwpENGgLjqrsWQfZkv1mRnBAKCD+vt=CC694E52Jg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Apr 27, 2023 at 11:04 AM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
> I think I may pursue a different approach to the problem that led me
> to think about this, at least for the moment. But I'm still curious
> about the general question: if somebody showed up with a well-written
> patch that added a GIN index to a system catalog, would that
> potentially be acceptable, or DOA?
Surely it would depend on the use case. Is this just an intellectual
exercise, or do you actually plan on doing something like this, in
whatever way? For example, does the posting list compression seem like
it might offer a compelling trade-off for some system catalog indexes
over and above B-Tree deduplication?
I'm asking this (at least in part) because it affects the answer. Lots
of stuff that GIN does that seems like it would be particularly tricky
to integrate with a system catalog is non-essential. It could be (and
sometimes is) selectively disabled. Whereas B-Tree indexes don't
really have any optional features (you can disable deduplication
selectively, but I believe that approximately nobody ever found it
useful to do so).
--
Peter Geoghegan
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2023-04-27 18:21:39 | Re: can system catalogs have GIN indexes? |
Previous Message | Tom Lane | 2023-04-27 18:16:35 | Re: Possible regression setting GUCs on \connect |