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

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

In response to

Responses

Browse pgsql-bugs by date

  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