Re: external sort performance - Mailing list pgsql-performance

From Jon Nelson
Subject Re: external sort performance
Date
Msg-id CAKuK5J26EWApdZHt9kKMhfh6y4pfjp8soJwXxoUexHjs8mYgMQ@mail.gmail.com
Whole thread Raw
In response to Re: external sort performance  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Responses Re: external sort performance
Re: external sort performance
List pgsql-performance
A follow-up question.
Even with both work_mem and maintenance_work_mem equal to 16GB, I see this:

LOG:  00000: begin index sort: unique = f, workMem = 16777216, randomAccess = f
and shortly thereafter:
LOG:  00000: switching to external sort with 59919 tapes: CPU
2.59s/13.20u sec elapsed 16.85 sec
and a while later:
LOG:  00000: finished writing run 1 to tape 0: CPU 8.16s/421.45u sec
elapsed 433.83 sec
LOG:  00000: performsort done (except 2-way final merge): CPU
9.53s/561.56u sec elapsed 576.54 sec
LOG:  00000: external sort ended, 181837 disk blocks used: CPU
12.90s/600.45u sec elapsed 625.05 sec


The first log statement is expected. The second log statement, however, isn't.
The total table size is (as noted earlier) about 5GB and, in fact, fit
into one nice hash table (approx 15GB in size).
Is the sorting that is necessary for index creation unable to use a
hash table? (This is a standard btree index).

--
Jon

pgsql-performance by date:

Previous
From: Jon Nelson
Date:
Subject: Re: external sort performance
Next
From: Tom Lane
Date:
Subject: Re: external sort performance