Re: track_planning causing performance regression

Поиск
Список
Период
Сортировка
От Julien Rouhaud
Тема Re: track_planning causing performance regression
Дата
Msg-id CAOBaU_YJUNCPuEAciSmFBS0EJ16Qa_pDH3mLjSpUnG4FtaSbzg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: track_planning causing performance regression  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Ответы Re: track_planning causing performance regression  (Fujii Masao <masao.fujii@oss.nttdata.com>)
Список pgsql-hackers
On Tue, Jun 29, 2021 at 10:45 AM Justin Pryzby <pryzby@telsasoft.com> wrote:
>
> We borrowed that language from the previous text:
>
> | Plannable queries (that is, SELECT, INSERT, UPDATE, and DELETE) are combined into a single pg_stat_statements entry
wheneverthey have identical query structures according to an internal hash calculation
 

Yes, but here's it's "identical query structure", which seems less
ambiguous than "identical structure" as iI think one could think it
refer to internal representation as much as as the query text.  And
it's also removing any doubt with the final "internal hash
calculation".

> Really, I'm only trying to fix where it currently says "a fewer kinds".

I agree that "fewer kinds" should be improved.

>        Enabling this parameter may incur a noticeable performance penalty,
> -      especially when a fewer kinds of queries are executed on many
> -      concurrent connections.
> +      especially when queries with identical structure are executed by many
> +      concurrent connections which compete to update a small number of
> +      pg_stat_statements entries.
>
> It could say "identical structure" or "the same queryid" or "identical queryid".

I think we should try to reuse the previous formulation.  How about
"statements with identical query structure"?  Or replace query
structure with "internal representation", in both places?



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Alvaro Herrera
Дата:
Сообщение: Re: Pipeline mode and PQpipelineSync()
Следующее
От: Bharath Rupireddy
Дата:
Сообщение: Re: Refactor "mutually exclusive options" error reporting code in parse_subscription_options