On Fri, Oct 11, 2019 at 3:14 AM Tom Lane <t...@sss.pgh.pa.us> wrote:
> 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.
That gave me another idea that would further reduce the bookkeeping
involved in creating new syscaches -- put declarations in the cache id
enum (syscache.h), like this:
#define DECLARE_SYSCACHE(cacheid,indexname,indexoid,numbuckets) cacheid
enum SysCacheIdentifier
{
DECLARE_SYSCACHE(AGGFNOID, pg_aggregate_fnoid_index,
AggregateFnoidIndexId, 16) = 0,
...
};
> > 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.
Looking at it again, the eq/hash functions are local and looked up via
GetCCHashEqFuncs(), but the runtime of that is surely miniscule, so I
left it alone.
> > 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 :-(.
I went ahead and did just enough to remove the relation-opening code.
Looking in the archives, I found this as a quick test:
echo '\set x 1' > x.txt
./inst/bin/pgbench -n -C -c 1 -f x.txt -T 10
Typical numbers:
master:
number of transactions actually processed: 4276
latency average = 2.339 ms
tps = 427.549137 (including connections establishing)
tps = 24082.726350 (excluding connections establishing)
patch:
number of transactions actually processed: 4436
latency average = 2.255 ms
tps = 443.492369 (including connections establishing)
tps = 21817.308410 (excluding connections establishing)
...which amounts to nearly 4% improvement in the first tps number,
which isn't earth-shattering, but it's something. Opinions? It
wouldn't be a lot of additional work to put together a WIP patch.
--
John Naylor https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
