Re: [BUG] pg_stat_statements and extended query protocol

Поиск
Список
Период
Сортировка
От Imseih (AWS), Sami
Тема Re: [BUG] pg_stat_statements and extended query protocol
Дата
Msg-id 75DD3F32-EB01-4540-8A19-1D8CDE490344@amazon.com
обсуждение исходный текст
Ответ на Re: [BUG] pg_stat_statements and extended query protocol  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [BUG] pg_stat_statements and extended query protocol
Список pgsql-hackers
> Why should that be the definition? Partial execution of a portal
> might be something that is happening at the driver level, behind the
> user's back. You can't make rational calculations of, say, plan
> time versus execution time if that's how "calls" is measured.

Correct, and there are also drivers that implement fetch size using
cursor statements, i.e. DECLARE CURSOR, FETCH CURSOR,
and each FETCH gets counted as 1 call.

I wonder if the right answer here is to track fetches as 
a separate counter in pg_stat_statements, in which fetch
refers to the number of times a portal is executed?

Regards,

Sami Imseih
Amazon Web Services (AWS)







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

Предыдущее
От: tender wang
Дата:
Сообщение: same query but different result on pg16devel and pg15.2
Следующее
От: Justin Pryzby
Дата:
Сообщение: Re: zstd compression for pg_dump