Re: Reducing the runtime of the core regression tests

Поиск
Список
Период
Сортировка
От Peter Geoghegan
Тема Re: Reducing the runtime of the core regression tests
Дата
Msg-id CAH2-WzmbiLgntzdUBrfiNWc44S7yzWHm=OamvgETiH=0OOPK8g@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Reducing the runtime of the core regression tests  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Reducing the runtime of the core regression tests  (Alvaro Herrera <alvherre@2ndquadrant.com>)
Список pgsql-hackers
On Thu, Apr 11, 2019 at 9:55 AM Tom Lane <tgl@sss.pgh.pa.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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Ashwin Agrawal
Дата:
Сообщение: Re: finding changed blocks using WAL scanning
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Pluggable Storage - Andres's take