Message-ID: <41d536d6-bd24-6e73-880d-0b0917054fec@yeah.net>
Date: Tue, 5 Sep 2023 17:27:03 +0800
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0)
 Gecko/20100101 Thunderbird/102.15.0
Subject: Re: Improving the heapgetpage function improves performance in common
 scenarios
To: John Naylor <john.naylor@enterprisedb.com>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
References: <a9f40066-3d25-a240-4229-ec2fbe94e7a5@yeah.net>
 <CAFBsxsHd1NajmezF8rReBoPfxxgi2GuyObni4kWmo8gWKPm3mg@mail.gmail.com>
Content-Language: en-US
From: Quan Zongliang <quanzongliang@yeah.net>
In-Reply-To: <CAFBsxsHd1NajmezF8rReBoPfxxgi2GuyObni4kWmo8gWKPm3mg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <https://www.postgresql.org/message-id/41d536d6-bd24-6e73-880d-0b0917054fec%40yeah.net>
Precedence: bulk


On 2023/9/5 16:15, John Naylor wrote:
> 
> On Thu, Aug 24, 2023 at 5:55 PM Quan Zongliang <quanzongliang@yeah.net 
> <mailto:quanzongliang@yeah.net>> wrote:
> 
>  > In the function heapgetpage. If a table is not updated very frequently.
>  > Many actions in tuple loops are superfluous. For all_visible pages,
>  > loctup does not need to be assigned, nor does the "valid" variable.
>  > CheckForSerializableConflictOutNeeded from
>  > HeapCheckForSerializableConflictOut function, it only need to inspect at
> 
> Thanks for submitting! A few weeks before this, there was another 
> proposal, which specializes code for all paths, not just one. That patch 
> also does so without duplicating the loop:
> 
> https://www.postgresql.org/message-id/20230716015656.xjvemfbp5fysjiea@awork3.anarazel.de <https://www.postgresql.org/message-id/20230716015656.xjvemfbp5fysjiea@awork3.anarazel.de>
> 
Nice patch. I'm sorry I didn't notice it before.

>  > the beginning of the cycle only once. Using vtune you can clearly see
>  > the result (attached heapgetpage.jpg).
>  >
>  > So by splitting the loop logic into two parts, the vtune results show
>  > significant improvement (attached heapgetpage-allvis.jpg).
> 
> For future reference, it's not clear at all from the screenshots what 
> the improvement will be for the user. In the above thread, the author 
> shares testing methodology as well as timing measurements. This is 
> useful for reproducibilty, as well as convincing others that the change 
> is important.
> 
Here's how I test it
    EXPLAIN ANALYZE SELECT * FROM orders;
Maybe the test wasn't good enough. Although the modified optimal result 
looks good. Because it fluctuates a lot. It's hard to compare. The 
results of vtune are therefore used.

My patch is mainly to eliminate:
1, Assignment of "loctup" struct variable (in vtune you can see that 
these 4 lines have a significant overhead: 0.4 1.0 0.2 0.4).
2. Assignment of the "valid" variable.(overhead 0.6)
3. HeapCheckForSerializableConflictOut function call.(overhead 0.6)

Although these are not the same overhead from test to test. But all are 
too obvious to ignore. The screenshots are mainly to show the three 
improvements mentioned above.

I'll also try Andres Freund's test method next.

> --
> John Naylor
> EDB: http://www.enterprisedb.com <http://www.enterprisedb.com>