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

From Christoph Berg
Subject Re: [PoC PATCH] Parallel dump to /dev/null
Date
Msg-id 20180320085406.GA32205@msg.df7cb.de
Whole thread Raw
In response to Re: [PoC PATCH] Parallel dump to /dev/null  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
Responses Re: [PoC PATCH] Parallel dump to /dev/null  (Michael Paquier <michael@paquier.xyz>)
List pgsql-hackers
Re: Alvaro Herrera 2018-03-05 <20180305165609.kq5y7uzy64o45vsg@alvherre.pgsql>
> The reason I noticed is I wondered about the amount of open() calls
> (plus zlib function calls) we would save by keeping an FD open to
> /dev/null, rather than opening it over and over for each object -- ie.,
> maybe not touch setFilePath() at all, if possible.  That looks perhaps
> too invasive, so maybe not.  But do audit other callsites that may open
> files.

In normal operation, the files are also opened individually, so
special-casing /dev/null seems overly specific to me (and I'd be very
surprised if it made any difference.)

For the feature to be useful in practise, it needs documentation.
People won't expect -Fd -f /dev/null to work because /dev/null is not
a directory.

Otherwise, +1 from me.
Christoph


pgsql-hackers by date:

Previous
From: Andrew Gierth
Date:
Subject: Re: PostgreSQL 10: Segmentation fault when using GROUPING SETS with all unsortable columns
Next
From: Anton Dignös
Date:
Subject: Re: IndexJoin memory problem using spgist and boxes