In response to "Guillaume Smet" <[EMAIL PROTECTED]>: > On 1/12/07, Bruce Momjian <[EMAIL PROTECTED]> 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. ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match