Re: [PERFORM] Slow BLOBs restoring

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Thu, Dec 9, 2010 at 12:28 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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