On 12/09/2010 10:05 AM, Tom Lane wrote:
I think what we need to do is make fix_dependencies
build a reverse lookup list of all the objects dependent on each TOC
object, so that the searching behavior in reduce_dependencies can be
eliminated outright. That will take O(N) time and O(N) extra spa
On Thu, Dec 9, 2010 at 10:05 AM, Tom Lane wrote:
> I wrote:
>> One fairly simple, if ugly, thing we could do about this is skip calling
>> reduce_dependencies during the first loop if the TOC object is a blob;
>> effectively assuming that nothing could depend on a blob. But that does
>> nothing a
I wrote:
> One fairly simple, if ugly, thing we could do about this is skip calling
> reduce_dependencies during the first loop if the TOC object is a blob;
> effectively assuming that nothing could depend on a blob. But that does
> nothing about the point that we're failing to parallelize blob
>
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
>>
On Thu, Dec 9, 2010 at 12:28 AM, Tom Lane wrote:
> Vlad Arkhipov writes:
>> 08.12.2010 22:46, Tom Lane writes:
>>> Are you by any chance restoring from an 8.3 or older pg_dump file made
>>> on Windows? If so, it's a known issue.
>
>> No, I tried Linux only.
>
> OK, then it's not the missing-data
Vlad Arkhipov writes:
> 08.12.2010 22:46, Tom Lane writes:
>> Are you by any chance restoring from an 8.3 or older pg_dump file made
>> on Windows? If so, it's a known issue.
> No, I tried Linux only.
OK, then it's not the missing-data-offsets issue.
> I think you can reproduce it. First I cre
