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

Re: Advice on selecting good values for work_mem?

From: "Simon Riggs" <simon(at)2ndquadrant(dot)com>
To: "Bill Moran" <wmoran(at)collaborativefusion(dot)com>
Cc: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>,<pgsql-performance(at)postgresql(dot)org>
Subject: Re: Advice on selecting good values for work_mem?
Date: 2006-12-28 13:19:44
Message-ID: 1167311984.3633.87.camel@silverbirch.site (view raw or flat)
Thread:
Lists: pgsql-performance
On Mon, 2006-12-18 at 16:18 -0500, Bill Moran wrote: 
> In response to Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> 
> > Bill Moran <wmoran(at)collaborativefusion(dot)com> writes:
> > > Does the creation of a temp file trigger any logging?
> > 
> > No; but it wouldn't be hard to add some if you wanted.  I'd do it at
> > deletion, not creation, so you could log the size the file reached.
> > See FileClose() in src/backend/storage/file/fd.c.
> 
> Is this along the lines of what you were thinking?  Is this acceptable
> to get pulled into the tree (maintaining local patches sucks ;)  I've
> only been using this patch a day and I'm already giddy about how much
> it helps tuning work memory sizes ...

You need to submit to patches, not here. Patch looks right, but needs
some extra things:

- activate based upon a GUC called trace_temp_files (?) to be added in
src/backend/utils/misc/guc.c - using a temp file is a problem only in
the eye of the beholder, so let the admin decide whether to show the
info or not (default not)

- level LOG not WARNING, with no hint message (?)

- message should be something like "temp file: size %s path: %s" so we
can see where the file was created (there is another todo about creating
temp files in different locations)

- add a trace point also for those who don't want to enable a parameter,
described here
http://www.postgresql.org/docs/8.2/static/dynamic-trace.html

e.g. PGTRACE1(temp__file__cleanup, filestats.st_size)


-- 
  Simon Riggs             
  EnterpriseDB   http://www.enterprisedb.com



In response to

pgsql-performance by date

Next:From: Tom LaneDate: 2006-12-28 14:56:54
Subject: Re: High update activity, PostgreSQL vs BigDBMS
Previous:From: Dave CramerDate: 2006-12-28 12:38:04
Subject: Re: High update activity, PostgreSQL vs BigDBMS

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