Re: Raw parse tree is not dumped to log - Mailing list pgsql-hackers

From Tatsuo Ishii
Subject Re: Raw parse tree is not dumped to log
Date
Msg-id 20250901.101308.872944159630955460.ishii@postgresql.org
Whole thread Raw
In response to Re: Raw parse tree is not dumped to log  (John Naylor <johncnaylorls@gmail.com>)
Responses Re: Raw parse tree is not dumped to log
List pgsql-hackers
> + if (unlikely(Debug_print_raw_parse))
> 
> Branch alignment surely shouldn't matter in a function that is called
> once per query?

According to my test, it seems using unlikely() makes a small but
non-negligible performance improvement over the code without
unlikely() for small queries.

Test method: Apply the latest patch (it needs rebasing) to master.
Disable debug_print_raw_parse. Run pgbench with following arguments:

$ pgbench -c 10 -j 10 -f bench.sql -T 60 test
cat bench.sql
SELECT 1;

I ran pgbench 3 times and here's the results:

case 1: with patch (unlikely() is used)
tps = 63279.645198 (without initial connection time)
tps = 62385.016698 (without initial connection time)
tps = 62950.431703 (without initial connection time)
average: 62871.697866

case 2: with patch (unlikely() is not used)
tps = 62462.798551 (without initial connection time)
tps = 63085.646278 (without initial connection time)
tps = 61361.373551 (without initial connection time)
average: 62303.272793

case 1 (62871.697866) / case 2 (62303.272793) = 1.009213

It seems case 1 (unlikely() is used) is about 0.9% faster than case
2 (unlikely() is used).

Comments?
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: hash + LRC better than CRC?
Next
From: Chao Li
Date:
Subject: Re: Fix an unnecessary cast calling elog in ExecHashJoinImpl