Re: Reducing the runtime of the core regression tests

From: Peter Geoghegan <pg(at)bowt(dot)ie>
To: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Reducing the runtime of the core regression tests
Date: 2019-04-26 01:44:30
Message-ID: CAH2-Wz=E_8-Y5st-4ggTOURjcEKSrd7XrjrDZQMdrXUi75o6fA@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
<alvherre(at)2ndquadrant(dot)com> wrote:
> Hmm, it's odd, because
> https://coverage.postgresql.org/src/backend/access/nbtree/nbtutils.c.gcov.html
> still shows that function doing that. pg_config shows:
>
> $ ./pg_config --configure
> '--enable-depend' '--enable-coverage' '--enable-tap-tests' '--enable-nls' '--with-python' '--with-perl' '--with-tcl' '--with-openssl' '--with-libxml' '--with-ldap' '--with-pam' 'CFLAGS=-O0'

So, we're currently using this on coverage.postgresql.org? We've switched?

I noticed a better example of weird line counts today, this time
within _bt_check_rowcompare():

1550 4 : cmpresult = 0;
1551 4 : if (subkey->sk_flags & SK_ROW_END)
1552 1292 : break;
1553 0 : subkey++;
1554 0 : continue;

I would expect the "break" statement to have a line count that is no
greater than that of the first two lines that immediately precede, and
yet it's far far greater (1292 is greater than 4). It looks like there
has been some kind of loop transformation.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Matsumura, Ryo 2019-04-26 01:51:53 RE: Patch: doc for pg_logical_emit_message()
Previous Message Peter Geoghegan 2019-04-25 23:46:08 Re: Improve search for missing parent downlinks in amcheck