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 -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
