Re: Reducing the runtime of the core regression tests

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reducing the runtime of the core regression tests
Date: 2019-04-11 17:02:02
Message-ID: CAH2-WzmbiLgntzdUBrfiNWc44S7yzWHm=OamvgETiH=0OOPK8g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Apr 11, 2019 at 9:55 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> So I concur that indexing.sql's fastpath test
> isn't adding anything useful coverage-wise, and will just nuke it.

Good.

> (It'd be interesting perhaps to check whether the results shown
> by coverage.postgresql.org are similarly unstable. They might be
> less so, since I believe those are taken over the whole check-world
> suite not just the core regression tests.)

I'm almost certain that they're at least slightly unstable. I mostly
find the report useful because it shows whether or not something gets
hit at all. I don't trust it to be very accurate.

I've noticed that the coverage reported on coverage.postgresql.org
sometimes looks contradictory, which can happen due to compiler
optimizations. I wonder if that could be addressed in some way,
because I find the site to be a useful resource. I would at least like
to know the settings used by its builds.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2019-04-11 17:11:36 Re: Pluggable Storage - Andres's take
Previous Message Ashwin Agrawal 2019-04-11 17:00:35 Re: finding changed blocks using WAL scanning