Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id E60BF2E0097 for ; Thu, 20 Mar 2008 11:58:42 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 38530-02 for ; Thu, 20 Mar 2008 11:58:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from mx00.pub.collaborativefusion.com (mx00.pub.collaborativefusion.com [206.210.89.199]) by postgresql.org (Postfix) with ESMTP id B25ED2E00A1 for ; Thu, 20 Mar 2008 11:58:35 -0300 (ADT) Received: from vanquish.ws.pitbpa0.priv.collaborativefusion.com (vanquish.ws.pitbpa0.priv.collaborativefusion.com [192.168.2.162]) (SSL: TLSv1/SSLv3,256bits,AES256-SHA) by wingspan with esmtp; Thu, 20 Mar 2008 10:58:33 -0400 id 00056407.47E27B99.00001749 Date: Thu, 20 Mar 2008 10:58:33 -0400 From: Bill Moran To: "Albe Laurenz" Cc: "Laurent Raufaste *EXTERN*" , pgsql-performance@postgresql.org Subject: Re: PG writes a lot to the disk Message-Id: <20080320105833.c539476d.wmoran@collaborativefusion.com> In-Reply-To: References: <669dc9710803190418g45002e87k19cb742579c1eeac@mail.gmail.com> <669dc9710803200348x64122249jd2ac5924d78a6da0@mail.gmail.com> Organization: Collaborative Fusion X-Mailer: Sylpheed 2.4.8 (GTK+ 2.12.8; i386-portbld-freebsd6.3) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200803/408 X-Sequence-Number: 29362 In response to "Albe Laurenz" : > Laurent Raufaste wrote: > > The problem was that the optimiser didn't know how to run the queries > > well and used millions of tuples for simple queries. For each tuple > > used it was updating some bit in the table file, resulting in a huge > > writing activity to that file. > > Good that you solved your problem. > > PostgreSQL doesn't write into the table files when it SELECTs data. > > Without an EXPLAIN plan it is impossible to say what PostgreSQL > was doing, but most likely it was building a large hash structure > or something similar and had to dump data into temporary files. As a parting comment on this topic ... Based on his previous messages, he was able to definitively tie filesystem write activity to specific tables, but also claimed that his PG logs showed only SELECT statements being executed. However, the part I wanted to comment on (and got busy yesterday so am only getting to it now) is that there's no guarantee that SELECT isn't modifying rows. SELECT nextval('some_seq'); is the simplest example I can imagine of a select that modifies database data, but it's hardly the only one. I suspect that the OP has procedures in his SELECTs that are modifying table data, or triggers that do it ON SELECT or something similar. Of course, without any details, this is purely speculation. -- Bill Moran Collaborative Fusion Inc. http://people.collaborativefusion.com/~wmoran/ wmoran@collaborativefusion.com Phone: 412-422-3463x4023