From 8087446b143fbb8da962a138fef393dfe8314e3a Mon Sep 17 00:00:00 2001 From: Bruce Momjian Date: Fri, 10 Oct 2003 02:08:42 +0000 Subject: [PATCH] > That's a fairly useless place to put it, though, since someone would > only think to look at sort_mem if they already had a clue. It should > be mentioned under bulk data load (in performance tips chapter) Attached is a doc patch that does this. The way I've worded it may not be the best, though. Neil Conway --- doc/src/sgml/perform.sgml | 30 +++++++++++++++++++++--------- doc/src/sgml/runtime.sgml | 7 ++++--- 2 files changed, 25 insertions(+), 12 deletions(-) diff --git a/doc/src/sgml/perform.sgml b/doc/src/sgml/perform.sgml index 6b7afe2b025..2eaab4d0f0d 100644 --- a/doc/src/sgml/perform.sgml +++ b/doc/src/sgml/perform.sgml @@ -1,5 +1,5 @@ @@ -751,11 +751,10 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; Use COPY FROM STDIN to load all the rows in one - command, instead of using - a series of INSERT commands. This reduces parsing, - planning, etc. - overhead a great deal. If you do this then it is not necessary to turn - off autocommit, since it is only one command anyway. + command, instead of using a series of INSERT + commands. This reduces parsing, planning, etc. overhead a great + deal. If you do this then it is not necessary to turn off + autocommit, since it is only one command anyway. @@ -764,9 +763,9 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; If you are loading a freshly created table, the fastest way is to - create the table, bulk-load with COPY, then create any - indexes needed - for the table. Creating an index on pre-existing data is quicker than + create the table, bulk load the table's data using + COPY, then create any indexes needed for the + table. Creating an index on pre-existing data is quicker than updating it incrementally as each row is loaded. @@ -780,6 +779,19 @@ SELECT * FROM x, y, a, b, c WHERE something AND somethingelse; + + Increase <varname>sort_mem</varname> + + + Temporarily increasing the sort_mem + configuration variable when restoring large amounts of data can + lead to improved performance. This is because when a B-tree index + is created from scratch, the existing content of the table needs + to be sorted. Allowing the merge sort to use more buffer pages + means that fewer merge passes will be required. + + + Run <command>ANALYZE</command> Afterwards diff --git a/doc/src/sgml/runtime.sgml b/doc/src/sgml/runtime.sgml index 4854d0fbaeb..4928aeda472 100644 --- a/doc/src/sgml/runtime.sgml +++ b/doc/src/sgml/runtime.sgml @@ -1,5 +1,5 @@ @@ -928,8 +928,9 @@ SET ENABLE_SEQSCAN TO OFF; by ORDER BY, merge joins, and CREATE INDEX. Hash tables are used in hash joins, hash-based aggregation, and hash-based processing of IN subqueries. Because - CREATE INDEX is used when restoring a database, it might - be good to temporarily increase this value during a restore. + CREATE INDEX is used when restoring a database, + increasing sort_mem before doing a large + restore operation can improve performance. -- 2.39.5