Skip site navigation (1) Skip section navigation (2)

Re: Pgstat.tmp file activity

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu>
Cc: pgsql-admin(at)postgresql(dot)org, "Dan Austin" <DAustin(at)au(dot)westfield(dot)com>
Subject: Re: Pgstat.tmp file activity
Date: 2005-12-23 04:28:30
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-admin
"Qingqing Zhou" <zhouqq(at)cs(dot)toronto(dot)edu> writes:
> ""Dan Austin"" <DAustin(at)au(dot)westfield(dot)com> 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

In response to

pgsql-admin by date

Next:From: Tom LaneDate: 2005-12-23 04:40:37
Subject: Re: WAL and pg_dump
Previous:From: Stephen FrostDate: 2005-12-23 01:50:01
Subject: Re: WAL and pg_dump

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group