Re: No flamefest please, MySQL vs. PostgreSQL AGAIN
От | Michael A Nachbaur |
---|---|
Тема | Re: No flamefest please, MySQL vs. PostgreSQL AGAIN |
Дата | |
Msg-id | 200305131232.14065.mike@nachbaur.com обсуждение исходный текст |
Ответ на | Re: No flamefest please, MySQL vs. PostgreSQL AGAIN (Will LaShell <will@lashell.net>) |
Ответы |
Re: No flamefest please, MySQL vs. PostgreSQL AGAIN
Re: No flamefest please, MySQL vs. PostgreSQL AGAIN Re: No flamefest please, MySQL vs. PostgreSQL AGAIN |
Список | pgsql-admin |
On Tuesday 13 May 2003 11:36 am, Will LaShell wrote: > On Tue, 2003-05-13 at 05:08, Andrew Sullivan wrote: > > On Mon, May 12, 2003 at 02:21:21PM -0400, Robert Treat wrote: > > > On Mon, 2003-05-12 at 10:32, Tom Lane wrote: > > > > in 7.4 either. Possibly 7.5. In the meantime, third-party solutions > > > > are still your only option, and PostgreSQL Inc's one is probably the > > > > best. > > > I wouldn't say they are your only options. there is the rserv code in > > > contrib which I've seen people post they have gotten working. There is > > The contrib/rserv code does indeed work for some people, and it is > > useful. It is nowhere close to handling large volumes, but for fewer > > than a few thousand writes an hour, it seems to be good. > > I'd like to put my two cents in on this one. We use rserv on our > cluster here, and we do a few hundred writes every 2 minutes. The > biggest thing that will cause slowdowns with rserv is not indexing the > replication id field. If there is an index for that it should work > fine. I tried rserv with a database that has over 1000 inserts per minute, and it would just sit there for days at the "Preparing snapshot" (on a Dual-Xeon/2GHz). I hadn't tried indexing the id column though. > I do have some rudimentary documentation on how we did it all, and I > suppose I should really get that sent in. Yes, Please, the documentation out there could definitely be improved with some other case studies.
В списке pgsql-admin по дате отправления: