Re: Reducing the runtime of the core regression tests
От | Peter Geoghegan |
---|---|
Тема | Re: Reducing the runtime of the core regression tests |
Дата | |
Msg-id | CAH2-Wz=E_8-Y5st-4ggTOURjcEKSrd7XrjrDZQMdrXUi75o6fA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Reducing the runtime of the core regression tests (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Ответы |
Re: Reducing the runtime of the core regression tests
|
Список | pgsql-hackers |
On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera <alvherre@2ndquadrant.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
В списке pgsql-hackers по дате отправления: