Re: Review: Revise parallel pg_restore's scheduling heuristic

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Review: Revise parallel pg_restore's scheduling heuristic
Дата
Msg-id 17267.1249312903@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  (Josh Berkus <josh@agliodbs.com>)
Re: Review: Revise parallel pg_restore's scheduling heuristic  (daveg <daveg@sonic.net>)
Список pgsql-hackers
"Kevin Grittner" <Kevin.Grittner@wicourts.gov> writes:
> Over the weekend I ran 40 restores of Milwaukee County's production
> data using Friday's snapshot with and without the patch.  I alternated
> between patched and unpatched.  It appears that this latest version is
> slightly slower for our production database on the same machine and
> configuration where the previous patch appeared to be 1% to 2% faster
> than unpatched (although I had fewer samples of that).

I think we can conclude that for this particular test case, the effects
of the patch are pretty much masked by noise.  I definitely see no way
that the latest version of the patch could really be slower than the
original; it has the same job-scheduling behavior and strictly less
list-munging overhead.  Now the patch could be slower than unpatched
as a result of different job-scheduling behavior ... but there's no
evidence here of a consistently measurable benefit or loss from that.

IIRC daveg was volunteering to do some tests with his own data; maybe
we should wait for those results.
        regards, tom lane


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

Предыдущее
От: David Fetter
Дата:
Сообщение: Re: Alpha releases: How to tag
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: CommitFest Status Summary - 2009-08-03