From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@bowt.ie>
cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Subject: Re: Reducing the runtime of the core regression tests
In-reply-to: 
 <CAH2-WznCYL49ci=Gvq-WqRoTOESBfNCkQRbw=zzJ-zRrp6dedQ@mail.gmail.com>
References: <735.1554935715@sss.pgh.pa.us>
 <CAH2-WznCYL49ci=Gvq-WqRoTOESBfNCkQRbw=zzJ-zRrp6dedQ@mail.gmail.com>
Comments: In-reply-to Peter Geoghegan <pg@bowt.ie>
	message dated "Wed, 10 Apr 2019 16:12:43 -0700"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <32386.1554938378.1@sss.pgh.pa.us>
Date: Wed, 10 Apr 2019 19:19:38 -0400
Message-ID: <32387.1554938378@sss.pgh.pa.us>
Precedence: bulk

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