Re: allowing extensions to control planner behavior

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: allowing extensions to control planner behavior
Date: 2024-08-27 16:36:07
Message-ID: CA+TgmoZV+O0DYj0h-_BG-S=3w-6CBoi5YzQ8YsUud1tREcXQaw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Tue, Aug 27, 2024 at 11:57 AM Joe Conway <mail(at)joeconway(dot)com> wrote:
> On the one hand, excluding indexes by initial vowels is definitely
> silly. On the other, I can see how it might be useful for an extension
> to exclude indexes based on a regex match of the index name or something
> similar, at least for testing.

Right. I deliberately picked a contrib module that implemented a silly
policy, because what I wanted to demonstrate with it is that this
little bit of infrastructure provides enough mechanism to implement
whatever policy you want. And I think it demonstrates it quite well,
because the whole contrib module to implement this has just 6 lines of
executable code. If you wanted a policy that would be more
realistically useful, you'd need more code, but only however much is
needed to implement your policy. All you need do is replace this
strchr call with something else:

if (name != NULL && strchr("aeiouAEIOU", name[0]) != NULL)
index->disabled = true;

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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2024-08-27 16:56:09 Re: allowing extensions to control planner behavior
Previous Message Nathan Bossart 2024-08-27 16:16:15 remove adaptive spins_per_delay code