Re: [PATCH] pg_dump: lock tables in batches

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PATCH] pg_dump: lock tables in batches
Дата
Msg-id 5016.1670453585@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PATCH] pg_dump: lock tables in batches  (Andres Freund <andres@anarazel.de>)
Ответы Re: [PATCH] pg_dump: lock tables in batches  (Jacob Champion <jchampion@timescale.com>)
Re: [PATCH] pg_dump: lock tables in batches  (Andres Freund <andres@anarazel.de>)
Список pgsql-hackers
Andres Freund <andres@anarazel.de> writes:
> With an artificial delay of 100ms, the perf difference between the batching
> patch and not using the batching patch is huge. Huge enough that I don't have
> the patience to wait for the non-batched case to complete.

Clearly, if you insert a sufficiently large artificial round-trip delay,
even squeezing a single command out of a pg_dump run will appear
worthwhile.  What I'm unsure about is whether it's worthwhile at
realistic round-trip delays (where "realistic" means that the dump
performance would otherwise be acceptable).  I think the reason I didn't
pursue this last year is that experimentation convinced me the answer
was "no".

> With batching pg_dump -s -h localhost t10000 took 0:16.23 elapsed, without I
> cancelled after 603 tables had been locked, which took 2:06.43.

Is "-s" mode actually a relevant criterion here?  With per-table COPY
commands added into the mix you could not possibly get better than 2x
improvement, and likely a good deal less.

            regards, tom lane



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

Предыдущее
От: Andrew Dunstan
Дата:
Сообщение: Re: Error-safe user functions
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Error-safe user functions