From: | Jon Nelson <jnelson+pgsql(at)jamponi(dot)net> |
---|---|
To: | |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: external sort performance |
Date: | 2011-11-17 20:11:30 |
Message-ID: | CAKuK5J26EWApdZHt9kKMhfh6y4pfjp8soJwXxoUexHjs8mYgMQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2011-11-18 00:33:49 | Re: external sort performance |
Previous Message | Jon Nelson | 2011-11-17 19:32:26 | Re: external sort performance |