From: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
---|---|
To: | Peter Geoghegan <pg(at)bowt(dot)ie> |
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 02:23:09 |
Message-ID: | 20190426022309.GA11555@alvherre.pgsql |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2019-Apr-25, Peter Geoghegan wrote:
> 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?
Yes, I changed it the day you first suggested it.
> 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.
Maybe it takes more than -O0 in cflags to disable those, but as I said,
the compile lines do show the -O0.
--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Geoghegan | 2019-04-26 02:29:41 | Re: Reducing the runtime of the core regression tests |
Previous Message | Andres Freund | 2019-04-26 02:02:48 | Re: REINDEX INDEX results in a crash for an index of pg_class since 9.6 |