Re: [PoC PATCH] Parallel dump to /dev/null - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [PoC PATCH] Parallel dump to /dev/null
Date
Msg-id 12960.1521557852@sss.pgh.pa.us
Whole thread Raw
In response to Re: [PoC PATCH] Parallel dump to /dev/null  (Christoph Berg <christoph.berg@credativ.de>)
Responses Re: [PoC PATCH] Parallel dump to /dev/null  (Christoph Berg <christoph.berg@credativ.de>)
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: file cloning in pg_upgrade and CREATE DATABASE
Next
From: Christoph Berg
Date:
Subject: Re: [PoC PATCH] Parallel dump to /dev/null