Re: subtransaction performance regression [kind of] due to snapshot caching

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: subtransaction performance regression [kind of] due to snapshot caching
Дата
Msg-id 947172.1617684433@sss.pgh.pa.us
обсуждение исходный текст
Ответ на subtransaction performance regression [kind of] due to snapshot caching  (Andres Freund <andres@anarazel.de>)
Ответы Re: subtransaction performance regression [kind of] due to snapshot caching
Список 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 по дате отправления:

Предыдущее
От: Fujii Masao
Дата:
Сообщение: Re: Get memory contexts of an arbitrary backend process
Следующее
От: Masahiko Sawada
Дата:
Сообщение: Re: Table refer leak in logical replication