From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Andres Freund <andres(at)anarazel(dot)de> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: subtransaction performance regression [kind of] due to snapshot caching |
Date: | 2021-04-06 05:34:02 |
Message-ID: | 949194.1617687242@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 2021-04-06 00:47:13 -0400, Tom Lane wrote:
>> Not wanting to distract from your point about xactCompletionCount,
>> but ... I wonder if we could get away with defining "isObjectPinned"
>> as "is the OID <= 9999" (and, in consequence, dropping explicit pin
>> entries from pg_depend). I had not previously seen a case where the
>> cost of looking into pg_depend for this info was this much of the
>> total query runtime.
> Couldn't we also treat FirstGenbkiObjectId to FirstBootstrapObjectId as
> pinned? That'd be another 400kB of database size...
Yeah, it'd require some close study of exactly what we want to pin
or not pin. Certainly everything with hand-assigned OIDs should
be pinned, but I think there's a lot of critical stuff like index
opclasses that don't get hand-assigned OIDs. On the other hand,
it's intentional that nothing in information_schema is pinned.
We might have to rejigger initdb so that there's a clearer
distinction between the OID ranges we want to pin or not.
Maybe we'd even get initdb to record the cutoff OID in
pg_control or someplace.
Anyway, just idle late-night speculation for now ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Rohit Bhogate | 2021-04-06 05:39:13 | Reference Leak with type |
Previous Message | Amit Langote | 2021-04-06 05:25:05 | Re: Table refer leak in logical replication |