Re: [PERFORMANCE] work_mem vs temp files issue
От | Jaime Casanova |
---|---|
Тема | Re: [PERFORMANCE] work_mem vs temp files issue |
Дата | |
Msg-id | 3073cc9b1001111311k7af04b71gd4104e07913bc349@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [PERFORMANCE] work_mem vs temp files issue (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: [PERFORMANCE] work_mem vs temp files issue
|
Список | pgsql-performance |
On Mon, Jan 11, 2010 at 3:18 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote: > Jaime Casanova <jcasanov@systemguards.com.ec> writes: >> LOG: begin tuple sort: nkeys = 1, workMem = 1024, randomAccess = f >> LOG: switching to bounded heapsort at 641 tuples: CPU 0.08s/0.13u sec elapsed 0.25 sec >> LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp8507.5", size 471010 [... some more temp files logged ...] >> LOG: internal sort ended, 118 KB used: CPU 0.10s/0.19u sec elapsed 0.33 sec > > Hmm. Not clear where the temp files are coming from, but it's *not* the > sort --- the "internal sort ended" line shows that that sort never went > to disk. What kind of plan is feeding the sort node? > i'm sure i have seen on disk sorts even when the files are small, but still i see a problem here... the temp files shoul be coming from hash operations but AFAICS the files are small and every hash operation should be using until work_mem memory, right? -- Atentamente, Jaime Casanova Soporte y capacitación de PostgreSQL Asesoría y desarrollo de sistemas Guayaquil - Ecuador Cel. +59387171157
Вложения
В списке pgsql-performance по дате отправления: