Re: Idea for improving speed of pg_restore

We already have on TODO:

* Turn off after-change writes if fsync is disabled (?)

I am wondering if we should remove the fsync option completely and just
have a "os_crash_unsafe" option that turns off fsync and WAL, or at
least all the WAL used for os crash recovery --- I think we still need
WAL to recover from dirty buffers that didn't get written to the OS
cache.

---------------------------------------------------------------------------

Tom Lane wrote:
> Christopher Browne <cbbrowne(at)acm(dot)org> writes:
> > Restoring a database involves, for each table:
> > 1. Reading table data from the source file;
> > 2. Writing data to the database file for the table;
> > 3. After that, reading the database file data, and
> > 4. Writing the sorted bits to the index file.
> > 5. Along with all of this, HEFTY amounts of updates to WAL.
>
> An idea that Marc and Jan and I were kicking around last night was to
> offer a GUC option to disable writes to WAL. During initial data load,
> you might as well go back to initdb if you have any failure, so why
> bother with full ACID compliance? I'm not sure if the performance
> benefit would be great enough to make it worth equipping the system
> with such a large-caliber foot-gun, but it's something to think about.
>
> I tend to agree with your doubts about parallelizing index builds,
> but there may be scenarios where it's a win; it'd depend on your
> relative CPU and disk horsepower. (Consider fast disk and multiple
> not-so-fast CPUs; serial index builds can only use one of the CPUs.)
> Question is, is it a big enough win for enough people to make it worth
> supporting?
>
> regards, tom lane
>
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
>

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073