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:
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
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'
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
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
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
>
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
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 >>
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
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.
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 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
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
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
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
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
19 matches
Mail list logo
