| 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
| 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 |