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`
|
| Список | 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:
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 по дате отправления: