Re: maintenance_work_mem and CREATE INDEX time - Mailing list pgsql-hackers

From Amit Langote
Subject Re: maintenance_work_mem and CREATE INDEX time
Date
Msg-id CA+HiwqGNP=gGwM9-X4VKL7pQ37M-y26U4JOdvNSVEo-L49OsLA@mail.gmail.com
Whole thread Raw
In response to maintenance_work_mem and CREATE INDEX time  (Amit Langote <amitlangote09@gmail.com>)
Responses Re: maintenance_work_mem and CREATE INDEX time
List pgsql-hackers
On Tue, Jul 23, 2013 at 1: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?
>

Upon further investigation, it is found that the delay to switch to
external sort caused by a larger value of maintenance_work_mem is
small compared to the total time of CREATE INDEX. So, plotting for a
number of maintenance_work_mem values shows that its effect is
negligible. Are there any other parts of external sort logic that
might make it slower with increasing values of maintenance_work_mem.
It seems merge order, number of tapes seem are related with
state->allowedMem.

Does that mean, external sort is affected by the value of
maintenance_work_mem in a way roughly similar to above?

--
Amit Langote


pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: anchovy failing on 9.1 and earlier since using gcc 4.8
Next
From: Andres Freund
Date:
Subject: Re: Back branches vs. gcc 4.8.0