X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (mx1.hub.org [200.46.208.251]) by postgresql.org (Postfix) with ESMTP id 5DC5A9FA2CB; Wed, 10 May 2006 16:06:43 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.208.251]) (amavisd-new, port 10024) with ESMTP id 52387-01; Wed, 10 May 2006 16:06:26 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey- X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id 31F7D9FA293; Wed, 10 May 2006 16:06:22 -0300 (ADT) Received: by noel.decibel.org (Postfix, from userid 1001) id 9902B56423; Wed, 10 May 2006 14:06:18 -0500 (CDT) Received: (hashcash-sendmail, from uid 1001); Wed, 10 May 2006 14:06:17 -0500 Date: Wed, 10 May 2006 14:06:17 -0500 From: "Jim C. Nasby" To: PFC Cc: Martijn van Oosterhout , Christian Kratzer , pgsql-performance@postgresql.org, pgsql-hackers@postgresql.org Subject: Re: [HACKERS] Big IN() clauses etc : feature proposal Message-ID: <20060510190617.GP99570@pervasive.com> References: <1147110142.32369.7.camel@archimedes> <20060508175013.GY99570@pervasive.com> <28288.1147111196@sss.pgh.pa.us> <20060509105214.P90693@vesihiisi.cksoft.de> <20060509113337.M90693@vesihiisi.cksoft.de> <20060509103632.GD29652@svana.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060510:lists@peufeu.com::6oI8MFcEC1sEinum:00wnV X-Hashcash: 1:20:060510:kleptog@svana.org::VjNsdqJd+1uwjGRN:00000000000000000000 0000000000000000000000001aNS X-Hashcash: 1:20:060510:ck@cksoft.de::dihZsR+n0vslkjEg:000000eR9 X-Hashcash: 1:20:060510:pgsql-performance@postgresql.org::VdKCtZK9hNMDcvH8:00000 0000000000000000000000003UAr X-Hashcash: 1:20:060510:pgsql-hackers@postgresql.org::QbeFix+IPoiJl31b:000000000 0000000000000000000000003jKb X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200605/268 X-Sequence-Number: 19055 On Tue, May 09, 2006 at 01:29:56PM +0200, PFC wrote: > 0.101 ms BEGIN > 1.451 ms CREATE TEMPORARY TABLE tmp ( a INTEGER NOT NULL, b INTEGER NOT > NULL, c TIMESTAMP NOT NULL, d INTEGER NOT NULL ) ON COMMIT DROP > 0.450 ms INSERT INTO tmp SELECT * FROM bookmarks ORDER BY annonce_id DESC > LIMIT 20 > 0.443 ms ANALYZE tmp > 0.365 ms SELECT * FROM tmp > 0.310 ms DROP TABLE tmp > 32.918 ms COMMIT > > CREATING the table is OK, but what happens on COMMIT ? I hear the > disk seeking frantically. > > With fsync=off, I get this : > > 0.090 ms BEGIN > 1.103 ms CREATE TEMPORARY TABLE tmp ( a INTEGER NOT NULL, b INTEGER NOT > NULL, c TIMESTAMP NOT NULL, d INTEGER NOT NULL ) ON COMMIT DROP > 0.439 ms INSERT INTO tmp SELECT * FROM bookmarks ORDER BY annonce_id DESC > LIMIT 20 > 0.528 ms ANALYZE tmp > 0.364 ms SELECT * FROM tmp > 0.313 ms DROP TABLE tmp > 0.688 ms COMMIT > > Getting closer ? > I'm betting on system catalogs updates. I get the same timings with > ROLLBACK instead of COMMIT. Temp tables have a row in pg_class... Have you tried getting a profile of what exactly PostgreSQL is doing that takes so long when creating a temp table? BTW, I suspect catalogs might be the answer, which is why Oracle has you define a temp table once (which does all the work of putting it in the catalog) and then you just use it accordingly in each individual session. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461