Re: [HACKERS] Improve catcache/syscache performance. - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] Improve catcache/syscache performance.
Date
Msg-id 1295.1507918074@sss.pgh.pa.us
Whole thread Raw
In response to Re: [HACKERS] Improve catcache/syscache performance.  (Andres Freund <andres@anarazel.de>)
Responses Re: [HACKERS] Improve catcache/syscache performance.
List 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


-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: [HACKERS] Pluggable storage
Next
From: Robert Haas
Date:
Subject: Re: [HACKERS] Re: protocol version negotiation (Re: LibpqPGRES_COPY_BOTH - version compatibility)