TRUNCATE+COPY optimization and --jobs=1 in pg_restore - Mailing list pgsql-hackers

From Takahiro Itagaki
Subject TRUNCATE+COPY optimization and --jobs=1 in pg_restore
Date
Msg-id 20100210115654.47E4.52131E4D@oss.ntt.co.jp
Whole thread Raw
Responses Re: TRUNCATE+COPY optimization and --jobs=1 in pg_restore
List pgsql-hackers
We have an optimization to bulkload date in pg_restore, but the code
only works in parallel restore (--jobs >= 2). Why don't we do the
same optimization in the serial restore (--jobs = 1) ?

We checks is_parallel to decide to use BEGIN-TRUNCATE-COPY:   if (is_parallel && te->created)
but we can always do it unless --single-transaction, right?   if (!ropt->single_txn && te->created)


[ in restore_toc_entry() ]
/** In parallel restore, if we created the table earlier in* the run then we wrap the COPY in a transaction and*
precedeit with a TRUNCATE. If archiving is not on* this prevents WAL-logging the COPY. This obtains a* speedup similar
tothat from using single_txn mode in* non-parallel restores.*/
 
if (is_parallel && te->created)     <==== HERE
{   /*    * Parallel restore is always talking directly to a    * server, so no need to see if we should issue BEGIN.
*/   StartTransaction(AH);
 
   /*    * If the server version is >= 8.4, make sure we issue    * TRUNCATE with ONLY so that child tables are not
*wiped.    */   ahprintf(AH, "TRUNCATE TABLE %s%s;\n\n",            (PQserverVersion(AH->connection) >= 80400 ?
   "ONLY " : ""),            fmtId(te->tag));
 
}


Regards,
---
Takahiro Itagaki
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: M Z
Date:
Subject: Re: CVS checkout source code for different branches
Next
From: M Z
Date:
Subject: Re: CVS checkout source code for different branches