From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Improve catcache/syscache performance. |
Date: | 2017-10-13 18:27:45 |
Message-ID: | 2202.1507919265@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2017-10-13 18:37:10 | Re: Pluggable storage |
Previous Message | Andres Freund | 2017-10-13 18:24:05 | Re: [HACKERS] pgsql: Improve performance of SendRowDescriptionMessage. |