Re: [PATCHES] Patch to log usage of temporary files

From: Bill Moran <wmoran(at)collaborativefusion(dot)com>
To: "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>
Cc: "Bruce Momjian" <bruce(at)momjian(dot)us>, pgsql-patches(at)postgresql(dot)org, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] Patch to log usage of temporary files
Date: 2007-01-12 21:26:03
Message-ID: 20070112162603.1793f0a4.wmoran@collaborativefusion.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

In response to "Guillaume Smet" <guillaume(dot)smet(at)gmail(dot)com>:

> On 1/12/07, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
> > Usually people don't want th query unless they ask for it. One nify
> > trick would be to print the query as DETAIL unless they are already
> > logging queries, but that just seems too complex. If you want the
> > query, why not just log them all?
>
> Because they can't? On a highly loaded production server, people
> usually don't log all the queries.
>
> Anyway, if it's too complicated to implement it, perhaps it's not
> worth it. I'm just curious to see how people will use this information
> if they don't know why the temp file was created.

I can only speak for myself but:
* I'm already using the patch in our lab. Since the lab is the same
hardware/config/etc as production, I can use the information to fine
tune configs that then get migrated to production after careful testing.
Since it's a lab environment, I'm free to turn on and off all sorts of
stuff that would be unwise in production. Thus the lab frequently has
full query logging turned on.
* Currently, our production systems have plenty of spare IO. The result
is that I _do_ log queries on production servers, and will continue
to do so until it becomes an issue. Additionally, we have lots of
room to grow with this hardware, so I can use the data collected about
temp file usage to justify additional RAM. Don't know how long I'll be
able to leave query logging enabled on the production systems, but I'm
taking advantage of it as long as possible.
* This variable can be tweaked per-session, which means if I've got queries
that I suspect are causing unwarranted temp files on a production server,
I can enable it on a per-connection basis to track down the problem and
work on a specific query, on production systems, without too much
disruption of the rest of the work that's going on:
set log_temp_files = 0;
<run suspect query>
set log_temp_files = -1;
<investigate logs>

At least, those are my current plans ...

--
Bill Moran
Collaborative Fusion Inc.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-01-12 21:41:57 Re: [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Previous Message Harald Armin Massa 2007-01-12 21:08:24 Missing error message on missing ssl-key-files

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2007-01-12 21:41:57 Re: [GENERAL] Corrupt database? 8.1/FreeBSD6.0
Previous Message Alvaro Herrera 2007-01-12 20:54:30 Re: [GENERAL] Corrupt database? 8.1/FreeBSD6.0