Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Дата
Msg-id 688984.1764786813@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: increased duration of stats_ext tests with -DCLOBBER_CACHE_ALWAYS
Список 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 по дате отправления: