Re: regression coverage gaps for gist and hash indexes

Hi,

On 4/1/23 1:13 AM, Andres Freund wrote:
> Hi,
> 
> On 2023-03-31 17:00:00 +0300, Alexander Lakhin wrote:
>> 31.03.2023 15:55, Tom Lane wrote:
>>> See also the thread about bug #16329 [1].  Alexander promised to look
>>> into improving the test coverage in this area, maybe he can keep an
>>> eye on the WAL logic coverage too.
>>
>> Yes, I'm going to analyze that area too. Maybe it'll take more time
>> (a week or two) if I encounter some bugs there (for now I observe anomalies
>> with gist__int_ops), but I will definitely try to improve the gist testing.
> 
> Because I needed it to verify the changes in the referenced patch, I wrote
> tests exercising killtuples based pruning for gist and hash.
> 

Thanks for the patch!

I did not looked at the detail but "just" checked that the coverage is now done.

And Indeed, when running "make check" + "027_stream_regress.pl":

I can see it moving from (without the patch):

function gistXLogDelete called 0 returned 0% blocks executed 0%
function gistRedoDeleteRecord called 0 returned 0% blocks executed 0%
function gistprunepage called 0 returned 0% blocks executed 0%
function _hash_vacuum_one_page called 0 returned 0% blocks executed 0%

to (with the patch):

function gistXLogDelete called 9 returned 100% blocks executed 100%
function gistRedoDeleteRecord called 5 returned 100% blocks executed 100% (thanks to 027_stream_regress.pl)
function gistprunepage called 9 returned 100% blocks executed 79%
function _hash_vacuum_one_page called 12 returned 100% blocks executed 94%

> For now I left the new tests in their own files. But possibly they should be
> in gist.sql and hash_index.sql respectively?

+1 to put them in gist.sql and hash_index.sql.

Regards,

-- 
Bertrand Drouvot
PostgreSQL Contributors Team
RDS Open Source Databases
Amazon Web Services: https://aws.amazon.com