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:07:54Z
Lists: pgsql-hackers
Andres Freund <andres@anarazel.de> writes: > On 2017-10-13 13:06:41 -0400, Robert Haas wrote: >> I don't think it's this patch's job to do it, but it seems like we >> ought to just invent some early-initialization step where things like >> this can happen, so that we don't have to branch here at all. > Yea, that'd be nice - it does show up in profiles. I'd tried to do > that, but it's not exactly trivial, so I decided to delay it. The > ordering when syscache stuff gets initialized is, uh, fragile. During > InitCatalogCache() the catalog is not ready for access. After that, we > access catcaches while not all catalogs are quite ready to be accessed. Yeah, I think the fragility vs. benefit tradeoff here is not very promising. 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. regards, tom lane
Commits
-
Improve sys/catcache performance.
- 141fd1b66ce6 11.0 landed
-
Add pg_noinline macro to c.h.
- a0247e7a11bb 11.0 landed
-
Add inline murmurhash32(uint32) function.
- 791961f59b79 11.0 landed