Re: [HACKERS] maintenance_work_mem and CREATE INDEX time
От | Amit Langote |
---|---|
Тема | Re: [HACKERS] maintenance_work_mem and CREATE INDEX time |
Дата | |
Msg-id | CA+HiwqG-mtKqXAc24bQmHBFUjAddUfxjBcjVq2yk-yebjGr0OA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] maintenance_work_mem and CREATE INDEX time (Jeff Janes <jeff.janes@gmail.com>) |
Ответы |
Re: [HACKERS] maintenance_work_mem and CREATE INDEX time
|
Список | pgsql-general |
On Wed, Jul 24, 2013 at 3:20 AM, Jeff Janes <jeff.janes@gmail.com> wrote: > On Mon, Jul 22, 2013 at 9:11 PM, Amit Langote <amitlangote09@gmail.com> wrote: >> Hello, >> >> While understanding the effect of maintenance_work_mem on time taken >> by CREATE INDEX, I observed that for the values of >> maintenance_work_mem less than the value for which an internal sort is >> performed, the time taken by CREATE INDEX increases as >> maintenance_work_increases. >> >> My guess is that for all those values an external sort is chosen at >> some point and larger the value of maintenance_work_mem, later the >> switch to external sort would be made causing CREATE INDEX to take >> longer. That is a smaller value of maintenance_work_mem would be >> preferred for when external sort is performed anyway. Does that make >> sense? > > The heap structure used in external sorts is cache-unfriendly. The > bigger the heap used, the more this unfriendliness becomes apparent. > And the bigger maintenance_work_mem, the bigger the heap used. > > The bigger heap also means you have fewer "runs" to merge in the > external sort. However, as long as the number of runs still fits in > the same number of merge passes, this is generally not a meaningful > difference. Does fewer runs mean more time (in whichever phase of external sort)? -- Amit Langote
В списке pgsql-general по дате отправления: