Re: Review: Revise parallel pg_restore's scheduling heuristic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Review: Revise parallel pg_restore's scheduling heuristic
Дата
Msg-id 15048.1248974655@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Review: Revise parallel pg_restore's scheduling heuristic  (Robert Haas <robertmhaas@gmail.com>)
Re: Review: Revise parallel pg_restore's scheduling heuristic  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> 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?

I think we've pretty much established that it doesn't make things
*worse*, so I'm sort of inclined to go ahead and apply it.  The
theoretical advantage of eliminating O(N^2) search behavior seems
like reason enough, even if it takes a ridiculous number of tables
for that to become significant.
        regards, tom lane


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

Предыдущее
От: Pavel Stehule
Дата:
Сообщение: Re: WIP: to_char, support for EEEE format
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Review: Revise parallel pg_restore's scheduling heuristic