Re: Statistics updates is delayed when using `commit and chain`

Поиск
Список
Период
Сортировка
От Lætitia Avrot
Тема Re: Statistics updates is delayed when using `commit and chain`
Дата
Msg-id CAB_COdjsWH+tjJHa4=FyUeSs+nCGegofiJwFmKzX+=xsGsP_Bw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Statistics updates is delayed when using `commit and chain`  (Japin Li <japinli@hotmail.com>)
Ответы Re: Statistics updates is delayed when using `commit and chain`  (Japin Li <japinli@hotmail.com>)
Список pgsql-bugs


Le sam. 10 juil. 2021 à 04:31, Japin Li <japinli@hotmail.com> a écrit :

On Fri, 09 Jul 2021 at 20:25, John Naylor <john.naylor@enterprisedb.com> wrote:
> On Fri, Jul 9, 2021 at 7:15 AM Japin Li <japinli@hotmail.com> wrote:
>> >                 /* Send out notify signals and transmit self-notifies */
>> >                 ProcessCompletedNotifies();
>> >
>> >                 /*
>> >                  * Also process incoming notifies, if any.  This is
> mostly to
>> >                  * ensure stable behavior in tests: if any notifies were
>> >                  * received during the just-finished transaction,
> they'll be
>> >                  * seen by the client before ReadyForQuery is.
>> >                  */
>> >                 if (notifyInterruptPending)
>> >                     ProcessNotifyInterrupt();
>
> It seems the above would also be skipped in chained transactions -- do we
> need to handle notifies as well?
>

Thanks for your review! Modified.

>> Attached fixes it by call pgstat_report_stat() when we a in COMMIT AND
> CHAIN mode.
>> Any thoughts?
>
> Do we need equivalent logic within the TBLOCK_SUBCOMMIT case also? Either
> way, a comment is probably in order.

Add a new function ProcessNotifiesAndStat() to process notifies and report
statistics, then call this function in TBLOCK_SUBCOMMIT, TBLOCK_END,
TBLOCK_ABORT_END, TBLOCK_ABORT_PENDING and TBLOCK_SUBCOMMIT cases.

Please consider v2 patch to review.

--
Regrads,
Japin Li.
ChengDu WenWu Information Technology Co.,Ltd.


Hello Japin,

Thank you for the patch. I read it and I find myself with one question: why do we update statistics even though there was a rollback? I know that that was the behaviour before, but is it still worth it?

I tested it against Postgres 14 Beta 2 and Postgres 15 (commit hash 4c64b51dc51f8ff7e3e51eebfe8d10469a577df1) and it worked like a charm for my use case:

laetitia=# select n_tup_ins from pg_stat_all_tables where relname = 'test'; 

 n_tup_ins 

-----------

         1

(1 row)


laetitia=# begin; 

BEGIN

laetitia=*#   insert into test (value) values ('bla');

INSERT 0 1

laetitia=*#   select n_tup_ins from pg_stat_all_tables where relname = 'test';

 n_tup_ins 

-----------

         1

(1 row)


laetitia=*# commit and chain; 

COMMIT

laetitia=*# select n_tup_ins from pg_stat_all_tables where relname = 'test';

 n_tup_ins 

-----------

         2

(1 row)


laetitia=*# commit; 

COMMIT

laetitia=#  select n_tup_ins from pg_stat_all_tables where relname = 'test';

 n_tup_ins 

-----------

         2

(1 row)
 Have a nice day,

Lætitia

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

Предыдущее
От: Andrew Kiellor
Дата:
Сообщение: Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types
Следующее
От: Japin Li
Дата:
Сообщение: Re: Statistics updates is delayed when using `commit and chain`