Re: [PERFORMANCE] work_mem vs temp files issue - Mailing list pgsql-performance

From Jaime Casanova
Subject Re: [PERFORMANCE] work_mem vs temp files issue
Date
Msg-id 3073cc9b1001111311k7af04b71gd4104e07913bc349@mail.gmail.com
Whole thread Raw
In response to Re: [PERFORMANCE] work_mem vs temp files issue  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [PERFORMANCE] work_mem vs temp files issue  (Tom Lane <tgl@sss.pgh.pa.us>)
List 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

Attachment

pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: performance config help
Next
From: Bob Dusek
Date:
Subject: Re: performance config help