X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 12ABF9DCAA5 for ; Sat, 3 Dec 2005 15:42:44 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 40699-06 for ; Sat, 3 Dec 2005 15:42:41 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from mail.mi8.com (d01gw04.mi8.com [63.240.6.44]) by postgresql.org (Postfix) with ESMTP id 9B0ED9DCA94 for ; Sat, 3 Dec 2005 15:42:39 -0400 (AST) Received: from 172.16.1.24 by mail.mi8.com with ESMTP (- Welcome to Mi8 Corporation www.Mi8.com (D4)); Sat, 03 Dec 2005 14:42:37 -0500 X-Server-Uuid: C8FB4D43-1108-484A-A898-3CBCC7906230 Received: from MI8NYCMAIL06.Mi8.com ([172.16.1.160]) by d01smtp03.Mi8.com with Microsoft SMTPSVC(6.0.3790.1830); Sat, 3 Dec 2005 14:42:04 -0500 Received: from 138.9.25.91 ([138.9.25.91]) 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 ; Sat, 3 Dec 2005 19:42:03 +0000 User-Agent: Microsoft-Entourage/11.2.1.051004 Date: Sat, 03 Dec 2005 11:42:02 -0800 Subject: Re: Database restore speed From: "Luke Lonergan" To: "Tom Lane" cc: "Stephen Frost" , "David Lang" , "Steve Oualline" , pgsql-performance@postgresql.org Message-ID: Thread-Topic: [PERFORM] Database restore speed Thread-Index: AcX3lFUed8lUKdKITBSk01X39MKJ9wArUycQ In-Reply-To: <8549.1133564459@sss.pgh.pa.us> MIME-Version: 1.0 X-OriginalArrivalTime: 03 Dec 2005 19:42:04.0657 (UTC) FILETIME=[A3524E10:01C5F841] X-WSS-ID: 6F8F2AA74084867716-02-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, score=1.253 required=5 tests=[RCVD_NUMERIC_HELO=1.253] X-Spam-Score: 1.253 X-Spam-Level: * X-Archive-Number: 200512/103 X-Sequence-Number: 15924 Tom, On 12/2/05 3:00 PM, "Tom Lane" wrote: > > Sure it does ... at least as long as you are willing to assume everybody > uses IEEE floats, and if they don't you have semantic problems > translating float datums anyhow. > > What we lack is documentation, more than functionality. Cool - sounds like the transport part might be there - the thing we desire is a file format that allows for efficient representation of portable binary datums. Last I looked at the Postgres binary dump format, it was not portable or efficient enough to suit the need. The efficiency problem with it was that there was descriptive information attached to each individual data item, as compared to the approach where that information is specified once for the data group as a template for input. Oracle's format allows for the expression of fixed width fields within the input file, and specifies the data type of the fields in the metadata. We could choose to support exactly the specification of the SQL*Loader format, which would certainly be general enough, and would have the advantage of providing a compatibility option with Oracle SQL*Loader input. Note that Oracle does not provide a similar functionality for the expression of *output* files, those that can be dumped from an Oracle database. Their mechanism for database dump is the exp/imp utility pair, and it is a proprietary "shifting sands" specification AFAIK. This limits the benefit of implementing the Oracle SQL*Loader compatibility to those customers who have designed utilities to emit that format, which may still be valuable. The alternative is to design a Postgres portable binary input file format. I'd like to see a record oriented format like that of FORTRAN unformatted, which uses bookends around each record to identify the length of each record. This allows for fast record oriented positioning within the file, and provides some self-description for integrity checking, etc. - Luke