Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Date
Msg-id 688984.1764786813@sss.pgh.pa.us
Whole thread Raw
In response to Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
List pgsql-hackers
I wrote:
> Yeah, I can imagine that constantly flushing the cached plan for
> that plpgsql function would be bad.  Let me see if I can reformulate
> that test without using a plpgsql function --- right offhand, it's
> not obvious why a built-in function wouldn't serve the purpose
> just as well.

I pushed a change for this.  On my Mac laptop, it brings the time
for stats_ext with -DCLOBBER_CACHE_ALWAYS down to ~8 minutes, from
I-didn't-have-the-patience-to-wait-but-it-would-have-been-hours.

BTW, I noticed that neither avocet nor trilobite seem to have
'use_installcheck_parallel' enabled in their BF config files.
That results in the installcheck steps taking longer than the
check step, when they should be the same time or shorter.
You could shave several hours off the animals' runtime by
enabling that.

(I'm not really sure why that's not on by default ... if the
check steps are automatically parallelized, why not installcheck?)

            regards, tom lane



pgsql-hackers by date:

Previous
From: Kirill Reshke
Date:
Subject: Re: [PATCH] Add enable_copy_program GUC to control COPY PROGRAM
Next
From: Paul A Jungwirth
Date:
Subject: Re: domain for WITHOUT OVERLAPS