On Thu, Apr 25, 2019 at 7:23 PM Alvaro Herrera wrote:
> Maybe it takes more than -O0 in cflags to disable those, but as I said,
> the compile lines do show the -O0.
Apparently, GCC does perform some optimizations at -O0, which is
barely acknowledged by its documentation:
http://www.complang.tuwi
On 2019-Apr-25, Peter Geoghegan wrote:
> On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
> 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 --confi
On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
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
On Fri, Apr 12, 2019 at 10:49 AM Peter Geoghegan wrote:
> It's definitely generally recommended that "-O0" be used, so I think
> that we can agree that that was an improvement, even if it doesn't fix
> the remaining problem that I noticed when I rechecked nbtutils.c.
I'm not sure that we can real
On Fri, Apr 12, 2019 at 10:24 AM Alvaro Herrera
wrote:
> I wonder if it would be useful to add --enable-debug. I think I
> purposefully removed that, but I don't remember any details about it.
As usual, this stuff is horribly under-documented. I think it's
possible that --enable-debug would hel
On 2019-Apr-12, Peter Geoghegan wrote:
> On Fri, Apr 12, 2019 at 9:31 AM Alvaro Herrera
> wrote:
> > Done. Do you have a preferred spot where the counts were wrong?
>
> Not really, but I can give you an example.
>
> Line counts for each of the two "break" statements within
> _bt_keep_natts_fa
On Fri, Apr 12, 2019 at 9:31 AM Alvaro Herrera wrote:
> Done. Do you have a preferred spot where the counts were wrong?
Not really, but I can give you an example.
Line counts for each of the two "break" statements within
_bt_keep_natts_fast() are exactly the same. I don't think that this
becaus
On 2019-Apr-11, Peter Geoghegan wrote:
> On Thu, Apr 11, 2019 at 11:00 AM Alvaro Herrera
> wrote:
> > ./configure --enable-depend --enable-coverage --enable-tap-tests
> > --enable-nls --with-python --with-perl --with-tcl --with-openssl
> > --with-libxml --with-ldap --with-pam >> $LOG 2>&1
> >
>
On Thu, Apr 11, 2019 at 11:00 AM Alvaro Herrera
wrote:
> ./configure --enable-depend --enable-coverage --enable-tap-tests --enable-nls
> --with-python --with-perl --with-tcl --with-openssl --with-libxml --with-ldap
> --with-pam >> $LOG 2>&1
>
> make -j4 >> $LOG 2>&1
> make -j4 -C contrib >> $LOG
On 2019-Apr-11, Peter Geoghegan wrote:
> 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
On Thu, Apr 11, 2019 at 9:55 AM Tom Lane 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
Peter Geoghegan writes:
> On Wed, Apr 10, 2019 at 4:56 PM Peter Geoghegan wrote:
>> The original fastpath tests don't seem particularly effective to me,
>> even without the oversight I mentioned. I suggest that you remove
>> them, since the minimal btree_index.sql fast path test is sufficient.
>
On Thu, 11 Apr 2019 at 16:44, Tom Lane wrote:
>
> David Rowley writes:
> > I was surprised to see nothing mentioned about attempting to roughly
> > sort the test order in each parallel group according to their runtime.
>
> I'm confused about what you have in mind here? I'm pretty sure pg_regress
David Rowley writes:
> I was surprised to see nothing mentioned about attempting to roughly
> sort the test order in each parallel group according to their runtime.
I'm confused about what you have in mind here? I'm pretty sure pg_regress
launches all the scripts in a group at the same time, so
On Thu, 11 Apr 2019 at 10:35, Tom Lane wrote:
> In no particular order, here's what I did:
I was surprised to see nothing mentioned about attempting to roughly
sort the test order in each parallel group according to their runtime.
Shorter running test coming last should reduce the chances of one
On Wed, Apr 10, 2019 at 4:56 PM Peter Geoghegan wrote:
> The original fastpath tests don't seem particularly effective to me,
> even without the oversight I mentioned. I suggest that you remove
> them, since the minimal btree_index.sql fast path test is sufficient.
To be clear: I propose that you
On Wed, Apr 10, 2019 at 4:19 PM Tom Lane wrote:
> > I'll come up with a patch to deal with this situation, by
> > consolidating the old and new tests in some way. I don't think that
> > your work needs to block on that, though.
>
> Should I leave out the part of my patch that creates index_fastpat
Peter Geoghegan writes:
> On Wed, Apr 10, 2019 at 3:35 PM Tom Lane wrote:
>> * Likewise, I split up indexing.sql by moving the "fastpath" test into
>> a new file index_fastpath.sql.
> I just noticed that the "fastpath" test actually fails to test the
> fastpath optimization -- the coverage we do
On Wed, Apr 10, 2019 at 3:35 PM Tom Lane wrote:
> I finally got some time to pursue that, and attached is a proposed patch
> that moves some tests around and slightly adjusts some other ones.
> To cut to the chase: on my workstation, this cuts the time for
> "make installcheck-parallel" from 21.9
Andres Freund writes:
> On 2019-04-10 18:35:15 -0400, Tom Lane wrote:
>> ... What I did instead was to shove
>> that test case and some related ones into a new plpgsql test file,
>> src/pl/plpgsql/src/sql/plpgsql_trap.sql, so that it's not part of the
>> core regression tests at all. (We've talke
Hi,
On 2019-04-10 18:35:15 -0400, Tom Lane wrote:
> on my workstation, this cuts the time for "make installcheck-parallel"
> from 21.9 sec to 13.9 sec, or almost 40%. I think that's a worthwhile
> improvement, considering how often all of us run those tests.
Awesome.
> * The plpgsql test ran m
21 matches
Mail list logo
