From: | Andrew Dunstan <andrew(at)dunslane(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jeff Davis <pgsql(at)j-davis(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: pg_dump object sorting |
Date: | 2008-04-14 20:43:22 |
Message-ID: | 4803C1EA.6000107@dunslane.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Andrew Dunstan <andrew(at)dunslane(dot)net> writes:
>
>> I should have expressed it better. The idea is to have pg_dump emit the
>> objects in an order that allows the restore to take advantage of sync
>> scans. So sync scans being disabled in pg_dump would not at all matter.
>>
>
> Unless you do something to explicitly parallelize the operations,
> how will a different ordering improve matters?
>
> I thought we had a paper design for this, and it involved teaching
> pg_restore how to use multiple connections. In that context it's
> entirely up to pg_restore to manage the ordering and ensure dependencies
> are met. So I'm not seeing how it helps to have a different sort rule
> at pg_dump time --- it won't really make pg_restore's task any easier.
>
>
>
Well, what actually got me going on this initially was that I got
annoyed by having indexes not grouped by table when I dumped out the
schema of a database, because it seemed a bit illogical. Then I started
thinking about it and it seemed to me that even without synchronised
scanning or parallel restoration, we might benefit from building all the
indexes of a given table together, especially if the whole table could
fit in either our cache or the OS cache.
cheers
andrew
From | Date | Subject | |
---|---|---|---|
Next Message | Brendan Jurd | 2008-04-14 20:44:54 | Re: Lessons from commit fest |
Previous Message | Tom Lane | 2008-04-14 20:39:49 | Re: Lessons from commit fest |