Here is an updated patch set that adjusts for the recently introduced
named captures. I will address the other issues later. I think the
first few patches in the series can be considered nonetheless.
On 15.06.23 09:45, John Naylor wrote:
> On Wed, May 31, 2023 at 4:58 AM Peter Eisentraut <peter@eisentraut.org
> <mailto:peter@eisentraut.org>> wrote:
> >
> > I want to report on my on-the-plane-to-PGCon project.
> >
> > The idea was mentioned in [0]. genbki.pl <http://genbki.pl> already
> knows everything about
> > system catalog indexes. If we add a "please also make a syscache for
> > this one" flag to the catalog metadata, we can have genbki.pl
> <http://genbki.pl> produce
> > the tables in syscache.c and syscache.h automatically.
> >
> > Aside from avoiding the cumbersome editing of those tables, I think this
> > layout is also conceptually cleaner, as you can more easily see which
> > system catalog indexes have syscaches and maybe ask questions about why
> > or why not.
>
> When this has come up before, one objection was that index declarations
> shouldn't know about cache names and bucket sizes [1]. The second
> paragraph above makes a reasonable case for that, however. I believe one
> alternative idea was for a script to read the enum, which would look
> something like this:
>
> #define DECLARE_SYSCACHE(cacheid,indexname,numbuckets) cacheid
>
> enum SysCacheIdentifier
> {
> DECLARE_SYSCACHE(AGGFNOID, pg_aggregate_fnoid_index, 16) = 0,
> ...
> };
>
> ...which would then look up the other info in the usual way from Catalog.pm.
>
> > As a possible follow-up, I have also started work on generating the
> > ObjectProperty structure in objectaddress.c. One of the things you need
> > for that is making genbki.pl <http://genbki.pl> aware of the syscache
> information. There
> > is some more work to be done there, but it's looking promising.
>
> I haven't studied this, but it seems interesting.
>
> One other possible improvement: syscache.c has a bunch of #include's,
> one for each catalog with a cache, so there's still a bit of manual work
> in adding a cache, and the current #include list is a bit cumbersome.
> Perhaps it's worth it to have the script emit them as well?
>
> I also wonder if at some point it will make sense to split off a
> separate script(s) for some things that are unrelated to the bootstrap
> data. genbki.pl <http://genbki.pl> is getting pretty large, and there
> are additional things that could be done with syscaches, e.g. inlined
> eq/hash functions for cache lookup [2].
>
> [1] https://www.postgresql.org/message-id/12460.1570734874@sss.pgh.pa.us
> <https://www.postgresql.org/message-id/12460.1570734874@sss.pgh.pa.us>
> [2]
> https://www.postgresql.org/message-id/20210831205906.4wk3s4lvgzkdaqpi%40alap3.anarazel.de
<https://www.postgresql.org/message-id/20210831205906.4wk3s4lvgzkdaqpi%40alap3.anarazel.de>
>
> --
> John Naylor
> EDB: http://www.enterprisedb.com <http://www.enterprisedb.com>