Re: Trying to add more tests to gistbuild.c

From: Matheus Alcantara <mths(dot)dev(at)pm(dot)me>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Aleksander Alekseev <aleksander(at)timescale(dot)com>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Pavel Borisov <pashkin(dot)elfe(at)gmail(dot)com>
Subject: Re: Trying to add more tests to gistbuild.c
Date: 2022-07-30 18:55:51
Message-ID: ozb7phO6DBvVdnq8BnMl_AMNsF1ANaGK7ffA6FSIIKnC-Zh9sxnY09-GfPBLriP_U1ecGpFe8EiXfWax3RejerK38CC6UJJjlKtuY_pQu3U=@pm.me
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

------- Original Message -------
On Friday, July 29th, 2022 at 19:53, Tom Lane tgl(at)sss(dot)pgh(dot)pa(dot)us wrote:

> I wonder if we can combine ideas from the two patches to get a
> better tradeoff of code coverage vs. runtime.

I was checking the Pavel patch and notice that he was using the fillfactor
parameter when creating the gist index. I changed my previous patch to include
this parameter and the code coverage of gistbuild.c and gistbuildbuffers.c was
improved to 97.7% and 92.8% respectively.

I'm attaching this new patch, could you please check if this change make sense
and also don't impact the test runtime?

> Another thing we might consider is to move the testing responsibility
> somewhere else. The reason I'm allergic to adding a lot of runtime
> here is that the core regression tests are invoked at least four times
> in a standard buildfarm run, often more. But that concern could be
> alleviated if we put the test somewhere else. Maybe contrib/btree_gist
> would be suitable?

I can't say much about it. If there's anything I can do here, please let
me know.

--
Matheus Alcantara

Attachment Content-Type Size
0001-Improve-test-coverage-of-gist-build.patch text/x-patch 2.0 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-07-30 19:39:38 Re: pg_buffercache: add sql test
Previous Message Tom Lane 2022-07-30 18:25:52 Re: Add test of pg_prewarm extenion