Re: generating catcache control data

John Naylor <john(dot)naylor(at)2ndquadrant(dot)com> writes:
> While digging through the archives, I found a thread from a couple
> years back about syscache performance. There was an idea [1] to
> generate the cache control data at compile time. That would to remove
> the need to perform database access to complete cache initialization,
> as well as the need to check in various places whether initialization
> has happened.

Right.

> 1. Generate the current syscache cacheinfo[] array and cacheid enum by
> adding a couple arguments to the declarations for system indexes, as
> in:
> #define DECLARE_UNIQUE_INDEX(name,oid,oid_macro,cacheid,num_buckets,decl)
> extern int no_such_variable

I do not like attaching this data to the DECLARE_UNIQUE_INDEX macros.
It's really no business of the indexes' whether they are associated
with a syscache. It's *certainly* no business of theirs how many
buckets such a cache should start off with.

I'd be inclined to make a separate file that's specifically concerned
with declaring syscaches, and put all the required data there.

> Relname, and relisshared are straightforward. For eq/hash functions,
> we could add metadata attributes to pg_type.dat for the relevant
> types. Tuple descriptors would get their attrs from schemapg.h.

I don't see a need to hard-wire more information than we do today, and
I'd prefer not to because it adds to the burden of creating new syscaches.
Assuming that the plan is for genbki.pl or some similar script to generate
the constants, it could look up all the appropriate data from the initial
contents for pg_opclass and friends. That is, basically what we want here
is for a constant-creation script to perform the same lookups that're now
done during backend startup.

> Is this something worth doing?

Hard to tell. It'd take a few cycles out of backend startup, which
seems like a worthy goal; but I don't know if it'd save enough to be
worth the trouble. Probably can't tell for sure without doing most
of the work :-(.

Perhaps you could break it up by building a hand-made copy of the
constants and then removing the runtime initialization code. This'd
be enough to get data on the performance change. Only if that looked
promising would you need to write the Perl script to compute the
constants.

regards, tom lane