Received: from maia.hub.org (unknown [200.46.204.183]) by mail.postgresql.org (Postfix) with ESMTP id DDB4E633C43 for ; Mon, 11 Jan 2010 17:38:01 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 56995-01 for ; Mon, 11 Jan 2010 21:37:51 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by mail.postgresql.org (Postfix) with ESMTP id AE0516341EB for ; Mon, 11 Jan 2010 17:36:25 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.2/8.14.2) with ESMTP id o0BLaMWm019929; Mon, 11 Jan 2010 16:36:22 -0500 (EST) To: Jaime Casanova cc: Robert Haas , decibel , psql performance list Subject: Re: [PERFORMANCE] work_mem vs temp files issue In-reply-to: <3073cc9b1001111311k7af04b71gd4104e07913bc349@mail.gmail.com> References: <3073cc9b0908191745o3dc63d95q6b9308ef5bd199f2@mail.gmail.com> <25315.1252881420@sss.pgh.pa.us> <3073cc9b1001111015t3888cbbex7171d61b952218da@mail.gmail.com> <603c8f071001111107v75276375g4d626dfc0efd8dc4@mail.gmail.com> <3073cc9b1001111114j7ddacd56p8966f9d61997a8b@mail.gmail.com> <3073cc9b1001111116x53427c9bm1e448128a3b4f6c6@mail.gmail.com> <18803.1263241120@sss.pgh.pa.us> <3073cc9b1001111311k7af04b71gd4104e07913bc349@mail.gmail.com> Comments: In-reply-to Jaime Casanova message dated "Mon, 11 Jan 2010 16:11:50 -0500" Date: Mon, 11 Jan 2010 16:36:22 -0500 Message-ID: <19928.1263245782@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=0.589 tagged_above=-10 required=5 tests=BAYES_00=-2.599, FH_DATE_PAST_20XX=3.188 X-Spam-Level: X-Archive-Number: 201001/221 X-Sequence-Number: 37101 Jaime Casanova writes: > the temp files shoul be coming from hash operations but AFAICS the > files are small and every hash operation should be using until > work_mem memory, right? No, when a hash spills to disk the code has to guess the partition sizes (number of buckets per partition) in advance. So it wouldn't be at all surprising if the actual sizes come out substantially different from work_mem. regards, tom lane