| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andreas Kretschmer <akretschmer(at)spamfence(dot)net> |
| Cc: | pgsql-general(at)postgresql(dot)org |
| Subject: | Re: work_mem = 900MB but Sort Method: external merge Disk: 304008kB |
| Date: | 2011-02-22 17:39:02 |
| Message-ID: | 3175.1298396342@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-general |
Andreas Kretschmer <akretschmer(at)spamfence(dot)net> writes:
> Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Reid Thompson <Reid(dot)Thompson(at)ateb(dot)com> writes:
>>> What am I missing that causes this to resort to sorting on disk?
>>
>> The in-memory space required to sort N tuples can be significantly
>> larger than the on-disk space,
> Question: when is the planner making the decision between in-memory and
> on-disk, at planning-time or at execution time with the knowledge about
> the real amount of tuples?
The planner doesn't make that decision. tuplesort.c always starts in
in-memory mode, and flips to on-disk when the actual amount of data in
its care exceeds work_mem. The planner guesses whether that will happen
while making cost estimates, but it's only an estimate.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2011-02-22 17:49:25 | Re: Notify rule |
| Previous Message | Reid Thompson | 2011-02-22 17:34:18 | Re: work_mem = 900MB but Sort Method: external merge Disk: 304008kB |