Received: from localhost (unknown [200.46.208.211]) by mail.postgresql.org (Postfix) with ESMTP id 080BC633DDA for ; Wed, 13 Jan 2010 11:43:56 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by localhost (mx1.hub.org [200.46.208.211]) (amavisd-maia, port 10024) with ESMTP id 03044-04 for ; Wed, 13 Jan 2010 15:43:35 +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 9196E633D47 for ; Wed, 13 Jan 2010 11:42:42 -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 o0DFgdXp010991; Wed, 13 Jan 2010 10:42:39 -0500 (EST) To: Robert Haas cc: Jaime Casanova , decibel , psql performance list Subject: Re: [PERFORMANCE] work_mem vs temp files issue In-reply-to: <603c8f071001130723v634cb3c3u1604ea69efb04e91@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> <3073cc9b1001122231m1a15d187lae2a8096a813361b@mail.gmail.com> <603c8f071001130723v634cb3c3u1604ea69efb04e91@mail.gmail.com> Comments: In-reply-to Robert Haas message dated "Wed, 13 Jan 2010 10:23:32 -0500" Date: Wed, 13 Jan 2010 10:42:38 -0500 Message-ID: <10990.1263397358@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-2.458 tagged_above=-10 required=5 tests=AWL=0.141, BAYES_00=-2.599 X-Spam-Level: X-Archive-Number: 201001/250 X-Sequence-Number: 37130 Robert Haas writes: > I had an idea at one point of making explain show the planned and > actual # of batches for each hash join. I believe that "actual # of > batches > 1" is isomorphic to "hash join went to disk". The code is > actually pretty easy; the hard part is figuring out what to do about > the UI. The choices seem to be: > 1. Create a new EXPLAIN option just for this - what would we call it? > 2. Think of some more, similar things and come up with a new EXPLAIN > option covering all of them - what else would go along with? > 3. Sandwhich it into an existing EXPLAIN option, most likely VERBOSE. > 4. Display it by default. Treat it the same as the Sort-node actual usage information. We did not add a special option when we added that. regards, tom lane