Re: Differential Code Coverage report for Postgres

From: Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>
To: Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Andres Freund <andres(at)anarazel(dot)de>, Álvaro Herrera <alvherre(at)kurilemu(dot)de>
Subject: Re: Differential Code Coverage report for Postgres
Date: 2025-09-05 15:14:06
Message-ID: CAOYmi+mybrn=kMQjAAm0i5+zifoAtPZdkA=diiFn4QwFoFaz7g@mail.gmail.com
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Sep 5, 2025 at 12:09 AM Nazir Bilal Yavuz <byavuz81(at)gmail(dot)com> wrote:
> I have been working on generating differential code coverage for
> Postgres and was able to do so with this script [1]. The script checks
> out HEAD and the latest release branch (currently REL_18_STABLE), then
> generates a differential coverage report.

This is fantastic timing! Differential coverage will be incredibly
useful to have for some upcoming test patches I am writing. :) I will
take a look.

I think LCOV's display table is a bit confusing, especially in how
they've chosen to include unchanged code in their percentage count for
the differential, but I suppose I'll get used to it.

On Fri, Sep 5, 2025 at 3:39 AM Oreo Yang <oreo(dot)yang(at)hotmail(dot)com> wrote:
> It looks very cool.
> So our goal over 90%?

I think our goal should be to pin behavior that needs to be pinned,
and use coverage as a helpful indicator as to what is missing.

(There are many ways to write low-quality tests that cover a lot of
code. I don't think we should be chasing numbers; we should be saying
"oh, 25% in this section is really bad" and then remedying that. If
you do that over and over again, you get really high coverage numbers
organically as a result of your higher-quality tests.)

Thanks,
--Jacob

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Andres Freund 2025-09-05 15:14:14 Re: Differential Code Coverage report for Postgres
Previous Message Robert Haas 2025-09-05 14:50:15 Re: Eager aggregation, take 3