Re: why postgresql over other RDBMS
От | Erik Jones |
---|---|
Тема | Re: why postgresql over other RDBMS |
Дата | |
Msg-id | A0702403-B532-42E6-A6B7-DBB72F0C0DE7@myemma.com обсуждение исходный текст |
Ответ на | Re: why postgresql over other RDBMS (Chris Browne <cbbrowne@acm.org>) |
Ответы |
Re: why postgresql over other RDBMS
|
Список | pgsql-general |
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
В списке pgsql-general по дате отправления: