Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id AF43D1337B66 for ; Thu, 9 Dec 2010 10:50:43 -0400 (AST) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 40632-08 for ; Thu, 9 Dec 2010 14:50:36 +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 D972D1337990 for ; Thu, 9 Dec 2010 10:50:35 -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 oB9EoUI5006340; Thu, 9 Dec 2010 09:50:30 -0500 (EST) To: Robert Haas cc: Vlad Arkhipov , pgsql-hackers@postgresql.org Subject: Re: [PERFORM] Slow BLOBs restoring In-reply-to: References: <4CFDF22B.7060209@dc.baikal.ru> <4CFF46BD.8070004@dc.baikal.ru> <14439.1291819581@sss.pgh.pa.us> <4D00559C.6070009@dc.baikal.ru> <29435.1291872532@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Thu, 09 Dec 2010 08:05:33 -0500" Date: Thu, 09 Dec 2010 09:50:30 -0500 Message-ID: <6339.1291906230@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.91 tagged_above=-5 required=5 tests=BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201012/700 X-Sequence-Number: 175962 Robert Haas writes: > On Thu, Dec 9, 2010 at 12:28 AM, Tom Lane wrote: >> * Mark BLOB TOC entries as SECTION_DATA, or somehow otherwise make them >> parallelizable.  Also break the BLOBS data item apart into an item per >> BLOB, so that that part's parallelizable.  Maybe we should combine the >> metadata and data for each blob into one TOC item --- if we don't, it >> seems like we need a dependency, which will put us back behind the >> eight-ball.  I think the reason it's like this is we didn't originally >> have a separate TOC item per blob; but now that we added that to support >> per-blob ACL data, the monolithic BLOBS item seems pretty pointless. >> (Another thing that would have to be looked at here is the dependency >> between a BLOB and any BLOB COMMENT for it.) > Is there any use case for restoring a BLOB but not the BLOB COMMENT or > BLOB ACLs? Can we just smush everything together into one section? The ACLs are already part of the main TOC entry for the blob. As for comments, I'd want to keep the handling of those the same as they are for every other kind of object. But that just begs the question of why comments are separate TOC entries in the first place. We could eliminate this problem if they became fields of object entries across the board. Which would be a non-backwards-compatible change in dump file format, but doing anything about the other issues mentioned above will require that anyway. I'm not certain however about whether it's safe to treat the object-metadata aspects of a blob as SECTION_DATA rather than SECTION_PRE_DATA. That will take a bit of investigation. It seems like there shouldn't be any fundamental reason for it not to work, but that doesn't mean there's not any weird assumptions buried someplace in pg_dump ... regards, tom lane