On May 25, 2007, at 11:36 AM, Chris Browne wrote:
[EMAIL PROTECTED] (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®
[EMAIL PROTECTED]
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
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
