Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: bertranddrouvot(dot)pg(at)gmail(dot)com
Cc: andres(at)anarazel(dot)de, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: Reconcile stats in find_tabstat_entry() and get rid of PgStat_BackendFunctionEntry
Date: 2023-02-13 07:40:58
Message-ID: 20230213.164058.1627673544865862342.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Mon, 13 Feb 2023 08:09:50 +0100, "Drouvot, Bertrand" <bertranddrouvot(dot)pg(at)gmail(dot)com> wrote in
>> I think this is useful beyond being able to generate those functions
>> with
>> macros. The fact that we had to deal with transactional code in
>> pgstatfuncs.c
>> meant that a lot of the relevant itnernals had to be exposed "outside"
>> pgstat,
>> which seems architecturally not great.
>>
> Right, good point.

Agreed.

> Removing the pfrees in V2 attached.

Ah, that sound good.

if (!entry_ref)
+ {
entry_ref = pgstat_fetch_pending_entry(PGSTAT_KIND_RELATION, InvalidOid, rel_id);
+ return tablestatus;
+ }

We should return something if the call returns a non-null value?

So, since we want to hide the internal from pgstatfuncs, the
additional flag should be gone. If the additional cost doesn't bother
anyone, I don't mind to remove the flag. The patch will get far
simpler by that.

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Masahiko Sawada 2023-02-13 07:50:57 Re: [PoC] Improve dead tuple storage for lazy vacuum
Previous Message Michael Paquier 2023-02-13 07:37:10 Re: recovery modules