Re: can system catalogs have GIN indexes? - Mailing list pgsql-hackers

From Robert Haas
Subject Re: can system catalogs have GIN indexes?
Date
Msg-id CA+Tgmoaa-J2w3TDuUmK7c5bXqpKfDG+1debVy6r6jjMAv9A6Xw@mail.gmail.com
Whole thread Raw
In response to Re: can system catalogs have GIN indexes?  (Peter Geoghegan <pg@bowt.ie>)
List pgsql-hackers
On Thu, Apr 27, 2023 at 2:17 PM Peter Geoghegan <pg@bowt.ie> wrote:
> On Thu, Apr 27, 2023 at 11:04 AM Robert Haas <robertmhaas@gmail.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).

My interest was in being able to index operators that GIN can index
and btree cannot.

--
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: David Steele
Date:
Subject: Re: Possible regression setting GUCs on \connect
Next
From: Nathan Bossart
Date:
Subject: Re: Possible regression setting GUCs on \connect