Re: Reducing the runtime of the core regression tests - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Reducing the runtime of the core regression tests
Date
Msg-id 32387.1554938378@sss.pgh.pa.us
Whole thread Raw
In response to Re: Reducing the runtime of the core regression tests  (Peter Geoghegan <pg@bowt.ie>)
Responses Re: Reducing the runtime of the core regression tests
List pgsql-hackers
Peter Geoghegan <pg@bowt.ie> writes:
> On Wed, Apr 10, 2019 at 3:35 PM Tom Lane <tgl@sss.pgh.pa.us> 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 have comes from another
> test in btree_index.sql, that I wrote back in December.

Oh!  Hmm.

> 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_fastpath.sql?
If we're going to end up removing that version of the test, there's no
point in churning the related lines beforehand.

One way or the other I want to get that test out of where it is,
because indexing.sql is currently the slowest test in its group.
But if you prefer to make btree_index run a bit longer rather than
inventing a new test script, that's no problem from where I stand.

            regards, tom lane



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: serializable transaction: exclude constraint violation (backed byGIST index) instead of ssi conflict
Next
From: Paul Martinez
Date:
Subject: Proper usage of ndistinct vs. dependencies extended statistics