On May 25, 2007, at 11:36 AM, Chris Browne wrote:
> erik@myemma.com (Erik Jones) writes:
>> On May 24, 2007, at 5:21 PM, Chris Browne wrote:
>>> Jan Wieck had a proposal to a similar effect, namely to give some
>>> way
>>> to get one connection to duplicate the state of another one.
>>>
>>> This would permit doing a neat parallel decomposition of pg_dump:
>>> you
>>> could do a 4-way parallelization of it that would function something
>>> like the following [elided]:
>>
>> Interesting. That's actually pretty close to the reindexing
>> strategy/
>> script that I use and I've been planning on extending it to a vacuum
>> strategy. So, I will add my support into someone building this kind
>> of support into pg_dump/restore.
>
> Well, I think that particular idea is dead for 8.3, as there wasn't
> agreement that there were enough relevant use-cases.
>
> If discussion gets bombarded with "yes, yes, that's useful for me
> too!" responses the next time it gets proposed, then that will
> increase the chances of acceptance.
>
> We seem to be suffering, as the community, and patch queue, grows,
> from the problem that features that are regarded as being useful only
> to small sets of users are seeing greater reluctance for acceptance.
> --
Well, in the current context, I'm less interested in shared
transaction state across processes and more in the ability to speed
up dumps with processes working in parallel. However, given that
shared transaction state would be necessary for a transactionally
consistent dump, I guess you could say that my interest there lies in
it as a means to an end.
As far as use cases go, it's really only useful for large databases
(in our case shortening our dump time to significantly less than 12
hours) and from what I've heard, until recently, postgres hasn't seen
much of a user base with seriously large databases, at least that
share their stats with the community. Now that postgres has garnered
a reputation as being a rock solid database and I'm seeing more and
more books and online tutorials pushing postgres (as opposed to the
previous de facto of mysql) that will most definitely change.
And, to finish up, is there any reason that pg_restore couldn't
already work with separate processes working in parallel?
Erik Jones
Software Developer | Emma®
erik@myemma.com
800.595.4401 or 615.292.5888
615.292.0777 (fax)
Emma helps organizations everywhere communicate & market in style.
Visit us online at http://www.myemma.com