X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 1C66352CBB for ; Tue, 26 Jul 2005 16:30:19 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 44598-08 for ; Tue, 26 Jul 2005 19:30:09 +0000 (GMT) Received: from mail.Mi8.com (mail.mi8.com [63.240.6.41]) by svr1.postgresql.org (Postfix) with ESMTP id 9456552C70 for ; Tue, 26 Jul 2005 16:30:04 -0300 (ADT) Received: from 172.16.1.110 by mail.Mi8.com with ESMTP (- GW01 Welcome to Mi8 Corporation www.Mi8.com); Tue, 26 Jul 2005 15:30:00 -0400 X-Server-Uuid: F1A2E19A-84E4-48DD-8F48-B475613F58B2 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.175]) by D01SMTP01.Mi8.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 26 Jul 2005 15:30:00 -0400 Received: from 67.103.45.218 ([67.103.45.218]) by MI8NYCMAIL06.Mi8.com ( [172.16.1.219]) via Exchange Front-End Server mi8owa.mi8.com ( [172.16.1.104]) with Microsoft Exchange Server HTTP-DAV ; Tue, 26 Jul 2005 15:30:00 -0500 User-Agent: Microsoft-Entourage/11.1.0.040913 Date: Tue, 26 Jul 2005 12:30:00 -0700 Subject: Re: [Bizgres-general] Re: faster INSERT with possible From: "Luke Lonergan" To: "Hannu Krosing" Cc: "John A Meinel" , "Dan Harris" , "bizgres-general" , pgsql-performance@postgresql.org Message-ID: In-Reply-To: <1122404195.31930.4.camel@fuji.krosing.net> MIME-Version: 1.0 X-OriginalArrivalTime: 26 Jul 2005 19:30:00.0612 (UTC) FILETIME=[6A0E4E40:01C59218] X-WSS-ID: 6EF850B221S789033-01-01 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.577 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO, RCVD_NUMERIC_HELO X-Spam-Level: * X-Archive-Number: 200507/402 X-Sequence-Number: 13643 Hannu, On 7/26/05 11:56 AM, "Hannu Krosing" wrote: > On T, 2005-07-26 at 11:46 -0700, Luke Lonergan wrote: > >> Yah - that's a typical approach, and it would be excellent if the COPY >> bypassed WAL for the temp table load. > > Don't *all* operations on TEMP tables bypass WAL ? Good question - do they? We had discussed the bypass as an elective option, or an automated one for special conditions (no index on table, empty table) or both. I thought that temp tables was one of those special conditions. Well - now that I test it, it appears you are correct, temp table COPY bypasses WAL - thanks for pointing it out! The following test is on a load of 200MB of table data from an ASCII file with 1 text column of size 145MB. - Luke ===================== TEST =========================== dgtestdb=# create temporary table temp1 (a text); CREATE TABLE dgtestdb=# \timing Timing is on. dgtestdb=# \i copy.ctl COPY Time: 4549.212 ms dgtestdb=# \i copy.ctl COPY Time: 3897.395 ms -- that's two tests, two loads of 200MB each, averaging 4.2 secs dgtestdb=# create table temp2 as select * from temp1; SELECT Time: 5914.803 ms -- a quick comparison to "CREATE TABLE AS SELECT", which bypasses WAL -- on bizgres dgtestdb=# drop table temp1; DROP TABLE Time: 135.782 ms dgtestdb=# drop table temp2; DROP TABLE Time: 3.707 ms dgtestdb=# create table temp1 (a text); CREATE TABLE Time: 1.667 ms dgtestdb=# \i copy.ctl COPY Time: 6034.274 ms dgtestdb=# -- This was a non-temporary table COPY, showing the slower performance of 6 secs. - Luke