Re: subtransaction performance regression [kind of] due to snapshot caching - Mailing list pgsql-hackers

From Tom Lane
Subject Re: subtransaction performance regression [kind of] due to snapshot caching
Date
Msg-id 947172.1617684433@sss.pgh.pa.us
Whole thread Raw
In response to subtransaction performance regression [kind of] due to snapshot caching  (Andres Freund <andres@anarazel.de>)
Responses Re: subtransaction performance regression [kind of] due to snapshot caching  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> The time in 14 is spent mostly below:
> -   94.58%     0.01%  postgres  postgres            [.] CreateFunction
>    - 94.57% CreateFunction
>       - 94.49% ProcedureCreate
>          - 90.95% record_object_address_dependencies
>             - 90.93% recordMultipleDependencies
>                - 89.65% isObjectPinned
>                   - 89.12% systable_getnext
>                      - 89.06% index_getnext_slot
>                         - 56.13% index_fetch_heap
>                            - 54.82% table_index_fetch_tuple
>                               + 53.79% heapam_index_fetch_tuple
>                                 0.07% heap_hot_search_buffer
>                                 0.01% ReleaseAndReadBuffer
>                                 0.01% LockBuffer
>                              0.08% heapam_index_fetch_tuple

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.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Fujii Masao
Date:
Subject: Re: Get memory contexts of an arbitrary backend process
Next
From: Masahiko Sawada
Date:
Subject: Re: Table refer leak in logical replication