Re: Review: Revise parallel pg_restore's scheduling heuristic

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Review: Revise parallel pg_restore's scheduling heuristic
Дата
Msg-id 4A716B4F02000025000290AD@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Review: Revise parallel pg_restore's scheduling heuristic  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> wrote: 
> with the default settings, the patched version ran an additional 1%
> faster than the unpatched; although I don't have enough samples to
> have a high degree of confidence it wasn't noise.  I'll run another
> slew of tests tonight with the existing dump file to confirm to
> debunk that result
The timings vary by up to 2.5% between runs, so that's the noise
level.  Five runs of each (alternating between the two) last night
give an average performance of 1.89% faster for the patched version. 
Combining that with yesterday's results starts to give me pretty good
confidence that the patch is beneficial for this database with this
configuration.  I haven't found any database or configuration where it
hurts.  (For most tests, adding up the results gave a net difference
measured in thousandths of a percent.)
Is that good enough, or is it still worth the effort of constructing
the artificial case where it might *really* shine?  Or should I keep
running with the "real" database a few more nights to get a big enough
sample to further increase the confidence level with this test?
-Kevin


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Brendan Jurd
Дата:
Сообщение: Re: WIP: to_char, support for EEEE format
Следующее
От: Brendan Jurd
Дата:
Сообщение: Re: WIP: to_char, support for EEEE format