Re: can system catalogs have GIN indexes?

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

In response to

Responses

Browse pgsql-hackers by date

  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