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

From: Christoph Berg <christoph(dot)berg(at)credativ(dot)de>
To: Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>
Cc: Michael Banck <michael(dot)banck(at)credativ(dot)de>, Andreas 'ads' Scherbaum <adsmail(at)wars-nicht(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org
Subject: Re: [PoC PATCH] Parallel dump to /dev/null
Date: 2018-03-20 08:54:07
Message-ID: 20180320085406.GA32205@msg.df7cb.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Re: Alvaro Herrera 2018-03-05 <20180305165609(dot)kq5y7uzy64o45vsg(at)alvherre(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Anton Dignös 2018-03-20 09:11:29 Re: IndexJoin memory problem using spgist and boxes
Previous Message Andrew Gierth 2018-03-20 08:38:45 Re: PostgreSQL 10: Segmentation fault when using GROUPING SETS with all unsortable columns