"Qingqing Zhou" <zhouqq@xxxxxxxxxxxxxx> writes: > ""Dan Austin"" <DAustin@xxxxxxxxxxxxxxxx> wrote >> I take it that the file gets renamed almost immediately because we can >> also see writes to the parent directory -- but never see the file itself >> using ls. >> > I think so. Right, the file is fully written under a temp name, and then rename()'d into place as pgstat.stat. rename is atomic per the Unix specs, so this ensures that any backend looking at pgstat.stat will see a complete consistent file. (This works on Unix anyway ... I'm not convinced that it does on Windows ...) But I still doubt that that's the source of your performance problem. Earlier today I tried a 200-client pgbench run with all stats options enabled, and I couldn't see that the stats collector was eating any undue share of time ... >> /export/data/pgsql/data/base/64920741/pgsql_tmp/pgsql_tmp966.9 >> >> What are these files used for? In this particular sample, that file was >> being written to a lot. Perhaps we're running out of memory for some >> sorting? > These files could be generated by several situations to store intermediate > data. For example, hash join and external sort. For sort, if you increase > sort_mem, then you may avoid/alleviate usage of temp file. AFAIR, increasing work_mem (nee sort_mem) will affect all the sources of temp-file usage, not only sorts. You want to be careful not to push it up so far that your system starts swapping --- see past discussions in the pgsql-performance archives. regards, tom lane
