Re: Improve catcache/syscache performance.

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Robert Haas <robertmhaas@gmail.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2017-10-13T18:27:45Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> On 2017-10-13 14:07:54 -0400, Tom Lane wrote:
>> One idea might be to see if we can precalculate all the control data
>> needed for the caches and set it up as compile-time constants,
>> a la Gen_fmgrtab.pl, rather than reading it from the catalogs during
>> startup.  That would make the code less dependent on initialization
>> order rather than more so.

> Hm. That sounds somewhat enticing. You're thinking of doing so for
> catcaches alone, or something grander, including the relcaches? I'd
> assume the former?

Yeah.  The relcaches are basically impossible to precalculate as constants
because they contain run-time variable data such as relfilenode.  I might
be wrong because I didn't go look, but offhand I think there is nothing in
the catcache control data that couldn't be predetermined.

> For catcaches the hardest part probably is that we need a TupleDesc. Per
> type function lookups, oids, should be fairly easy in contrast.

We already have a mechanism for precalculated TupleDescs for system
catalogs, cf src/backend/catalog/schemapg.h.  Right now we only apply
that for a few "bootstrap" system catalogs, but I don't really see
a reason we couldn't use it for every catalog that has a catcache.

			regards, tom lane


Commits

  1. Improve sys/catcache performance.

  2. Add pg_noinline macro to c.h.

  3. Add inline murmurhash32(uint32) function.