sql/catalog/descs: fix perf regression

[ajwerner]

This commit in #71936 had the unfortunate side-effect of allocating and forcing reads on the uncommittedDescriptors set even when we aren't looking for the system database. This has an outsized impact on the performance of the single-node, high-core-count KV runs. Instead of always initializing the system database, just do it when we access it.

name             old ops/s   new ops/s   delta
KV95-throughput  88.6k ± 0%  94.8k ± 1%   +7.00%  (p=0.008 n=5+5)

name             old ms/s    new ms/s    delta
KV95-P50          1.60 ± 0%   1.40 ± 0%  -12.50%  (p=0.008 n=5+5)
KV95-Avg          0.60 ± 0%   0.50 ± 0%  -16.67%  (p=0.008 n=5+5)

The second commit is more speculative and came from looking at a profile where 1.6% of the allocated garbage was due to that NameInfo even though we'll never, ever hit it.

Fixes #72499

[cockroach-teamcity]

This change is 

[ajwerner]

With the second commit:

name             old ops/s   new ops/s   delta
KV95-throughput  88.7k ± 0%  95.7k ± 0%   +7.82%  (p=0.008 n=5+5)

name             old ms/s    new ms/s    delta
KV95-P50          1.60 ± 0%   1.40 ± 0%  -12.50%  (p=0.008 n=5+5)
KV95-Avg          0.60 ± 0%   0.50 ± 0%  -16.67%  (p=0.008 n=5+5)

[fqazi]

Reviewed 1 of 1 files at r1, 2 of 2 files at r2, 4 of 4 files at r3, all commit messages.
Reviewable status: complete! 0 of 0 LGTMs obtained (waiting on @postamar)

[postamar]

This all seems uncontroversially good to me.

A thought popped to mind after seeing your handling of the system db: this is undoubtedly worth it because the system db descriptor shows up in the uncommitted descriptor set in a great many transactions, but how about extending this treatment to all descriptors which are accessed only for reads? Such as things are, we always stuff them in the uncommitted descriptor set regardless if we want them mutable or not. It seems to me that we could break down the uncommitted layer in the collection into two sub-layers: a "cached immutable" layer and a real "uncommitted" layer. Reading a descriptor as mutable would evict it from the "cached immutable" layer. The latter could be pre-populated with the system db descriptor. Is there anything preventing us from doing this?

[ajwerner]

Such as things are, we always stuff them in the uncommitted descriptor set regardless if we want them mutable or not. It seems to me that we could break down the uncommitted layer in the collection into two sub-layers: a "cached immutable" layer and a real "uncommitted" layer. Reading a descriptor as mutable would evict it from the "cached immutable" layer. The latter could be pre-populated with the system db descriptor. Is there anything preventing us from doing this?

Nothing preventing us from doing this. Will pull it into a separate PR.

[ajwerner]

Flaked on #72718.

bors r+

[craig]

Build succeeded:

• GitHub CI (Cockroach)