Re: external sort performance

Поиск
Список
Период
Сортировка
От Jon Nelson
Тема Re: external sort performance
Дата
Msg-id CAKuK5J26EWApdZHt9kKMhfh6y4pfjp8soJwXxoUexHjs8mYgMQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: external sort performance  (Jon Nelson <jnelson+pgsql@jamponi.net>)
Ответы Re: external sort performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: external sort performance  (Josh Berkus <josh@agliodbs.com>)
Список 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 по дате отправления:

Предыдущее
От: Jon Nelson
Дата:
Сообщение: Re: external sort performance
Следующее
От: Tom Lane
Дата:
Сообщение: Re: external sort performance