Re: Add missing stats_reset column to pg_stat_database_conflicts view - Mailing list pgsql-hackers

From Chao Li
Subject Re: Add missing stats_reset column to pg_stat_database_conflicts view
Date
Msg-id A1535A8F-65AF-4C3D-ACBE-25891CB5D38B@gmail.com
Whole thread Raw
In response to Re: Add missing stats_reset column to pg_stat_database_conflicts view  (Fujii Masao <masao.fujii@gmail.com>)
List pgsql-hackers

> On Mar 13, 2026, at 21:25, Fujii Masao <masao.fujii@gmail.com> wrote:
>
> On Fri, Mar 13, 2026 at 5:47 PM Chao Li <li.evan.chao@gmail.com> wrote:
>>
>>
>>
>>> On Mar 13, 2026, at 04:39, Sami Imseih <samimseih@gmail.com> wrote:
>>>
>>>> I also made some cosmetic indentation fixes in the docs.
>>>> The v6 patch is attached.
>>>
>>> Just one more minor comment fix I noticed.
>>>
>>> "Test that reset works for pg_stat_database"
>>>
>>> to:
>>>
>>> "Test that reset works for pg_stat_database and pg_stat_database_conflicts"
>>>
>>> --
>>> Sami
>>> <v7-0001-Add-stats_reset-column-to-pg_stat_database_confli.patch>
>
> I've pushed the patch. Thanks!
>
>
>> I still saw (SELECT current_database()) in v7. Does it have any special meaning than just current_database()?
>
> No. I think it was used by the patch simply because the existing tests
> for stats reset already use it.
>
> Regards,
>
> --
> Fujii Masao

Hi Fujii-san,

If the only reason for using (SELECT current_database()) is to follow the existing code, would it make sense to update
thecode to use current_database() instead? 

Looking at the execution plans below:
```
evantest=# explain select (select current_database());
                    QUERY PLAN
---------------------------------------------------
 Result  (cost=0.01..0.02 rows=1 width=64)
   InitPlan expr_1
     ->  Result  (cost=0.00..0.01 rows=1 width=64)
(3 rows)

evantest=# explain select current_database();
                QUERY PLAN
-------------------------------------------
 Result  (cost=0.00..0.01 rows=1 width=64)
(1 row)
```

The nested SELECT introduces an unnecessary InitPlan, which adds extra work to execute.

Another point is that the nested SELECT may mislead users or code readers into thinking it is required. For example, I
oftenlook at regression test scripts to check how SQL statements are used in practice, and I consider them an important
sourceof reference. Because of that, I think it's better for the test scripts to demonstrate the simplest and most
appropriateusage when possible. 

I searched through the test scripts, and it looks like only stats.sql uses this pattern. So I attached a small patch
thatreplaces all (SELECT current_database()) with current_database(). 

Best regards,
--
Chao Li (Evan)
HighGo Software Co., Ltd.
https://www.highgo.com/





Attachment

pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: pgcrypto/des tests fail on riscv64 due to clang's code generation anomaly
Next
From: Japin Li
Date:
Subject: Re: Use SMgrRelation instead of SMgrRelationData * in pgaio_io_set_target_smgr()