Re: [COMMITTERS] pgsql: Bloom index contrib module - Mailing list pgsql-hackers

From Noah Misch
Subject Re: [COMMITTERS] pgsql: Bloom index contrib module
Date
Msg-id 20160409234332.GA1747447@tornado.leadboat.com
Whole thread Raw
In response to Re: [COMMITTERS] pgsql: Bloom index contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [COMMITTERS] pgsql: Bloom index contrib module  (Peter Geoghegan <pg@heroku.com>)
Re: [COMMITTERS] pgsql: Bloom index contrib module  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sat, Apr 09, 2016 at 11:50:08AM -0400, Tom Lane wrote:
> Teodor Sigaev <teodor@sigaev.ru> writes:
> > Bloom index contrib module
> 
> Would it be possible to dial down the amount of runtime consumed by
> the regression tests for this module?
> 
> On my primary dev machine, "make installcheck" in contrib/bloom takes
> 4.5 seconds, which seems a bit excessive when make installcheck across
> all the rest of contrib takes 22 seconds.
> 
> On prairiedog, which admittedly is one of the slower buildfarm animals
> (though far from the slowest), the contrib-install-check-C step went
> from 2:54 immediately before this patch went in to 4:28 immediately
> after.
> 
> That seems out of line for a single contrib module, especially one of
> unproven usefulness.

I find this added test duration reasonable.  If someone identifies a way to
realize similar coverage with lower duration, I'd value that contribution.  -1
for meeting some runtime target at the expense of coverage.  Older modules
have rather little test coverage, so they're poor as benchmarks.

A feature's lack of usefulness can be a good reason to exclude it from the
tree entirely, but it's a bad reason to slash the feature's test cases.  (I
have not evaluated the usefulness of this access method.)



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: proposal: PL/Pythonu - function ereport
Next
From: Peter Geoghegan
Date:
Subject: Re: [COMMITTERS] pgsql: Bloom index contrib module