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
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 |