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
|
Список | 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 по дате отправления: