From: | Lætitia Avrot <laetitia(dot)avrot(at)gmail(dot)com> |
---|---|
To: | Japin Li <japinli(at)hotmail(dot)com> |
Cc: | John Naylor <john(dot)naylor(at)enterprisedb(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Statistics updates is delayed when using `commit and chain` |
Date: | 2021-07-12 12:56:18 |
Message-ID: | CAB_COdjsWH+tjJHa4=FyUeSs+nCGegofiJwFmKzX+=xsGsP_Bw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Le sam. 10 juil. 2021 à 04:31, Japin Li <japinli(at)hotmail(dot)com> a écrit :
>
> On Fri, 09 Jul 2021 at 20:25, John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
> wrote:
> > On Fri, Jul 9, 2021 at 7:15 AM Japin Li <japinli(at)hotmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Japin Li | 2021-07-12 13:34:18 | Re: Statistics updates is delayed when using `commit and chain` |
Previous Message | Andrew Kiellor | 2021-07-12 08:44:05 | Re: BUG #17101: Inconsistent behaviour when querying with anonymous composite types |