Re: [PoC PATCH] Parallel dump to /dev/null

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [PoC PATCH] Parallel dump to /dev/null
Дата
Msg-id 12960.1521557852@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [PoC PATCH] Parallel dump to /dev/null  (Christoph Berg <christoph.berg@credativ.de>)
Ответы Re: [PoC PATCH] Parallel dump to /dev/null  (Christoph Berg <christoph.berg@credativ.de>)
Список pgsql-hackers
Christoph Berg <christoph.berg@credativ.de> writes:
> Re: Michael Paquier 2018-03-20 <20180320135720.GE13368@paquier.xyz>
>> Now, why are people using pg_dump > /dev/null?  Mainly the lack of
>> better tools, which would be actually able to detect pages in corrupted
>> pages in one run, and not only heap pages.  I honestly think that
>> amcheck is something that we sould more focus on and has more potential
>> on the matter, and that we are just complicating pg_dump to do something
>> it is not designed for, and would do it badly anyway.

FWIW, I've been wondering the same thing about this patch.  I hadn't
bothered to actually read the thread up to now, but the title was
enough to make me think "do we really need that?"

> Still, people are using it for that purpose now, and speeding it up
> would just be a non-intrusive patch.

If it were non-intrusive, that would be OK, but after a quick look
at the latest patch I can't say I find it so.  It seems to add a bunch
of poorly-defined additional states to each pg_dump format module.

It might help if the patch were less enthusiastic about trying to
"optimize" by avoiding extra file opens/closes in the case of output
to /dev/null.  That seems to account for a lot of the additional
complication, and I can't see a reason that it'd be worth it.

            regards, tom lane


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

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: file cloning in pg_upgrade and CREATE DATABASE
Следующее
От: Christoph Berg
Дата:
Сообщение: Re: [PoC PATCH] Parallel dump to /dev/null