> On 22 Jan 2020, at 23:07, Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Wed, Jan 22, 2020 at 3:28 PM Magnus Hagander <magnus@hagander.net> wrote:
>>> I think the argument about adding catalog flags adding overhead is
>>> pretty much bogus. Fixed-width fields in catalogs are pretty cheap.
>>
>> If that's the general view, then yeah our "cost calculations" were
>> off. I guess I may have been colored by the cost of adding statistics
>> counters, and had that influence the thinking. Incorrect judgement on
>> that cost certainly contributed to the decision. back then.
>
> For either statistics or for pg_class, the amount of data that we have
> to manage is proportional to the number of relations (which could be
> big) multiplied by the data stored for each relation. But the
> difference is that the stats file has to be rewritten, at least on a
> per-database basis, very frequently, while pg_class goes through
> shared-buffers and so doesn't provoke the same stupid
> write-the-whole-darn-thing behavior. That is a pretty key difference,
> IMHO.
I think the cost is less about performance and more about carrying around an
attribute which wont be terribly interesting during the cluster lifetime,
except for the transition. But, it's as you say probably a manageable expense.
A bigger question is how to handle the offline capabilities. pg_checksums can
enable or disable checksums in an offline cluster, which will put the cluster
in a state where the pg_control file and the catalog don't match at startup.
One strategy could be to always trust the pg_control file and alter the catalog
accordingly, but that still leaves a window of inconsistent cluster state.
cheers ./daniel