Re: database file size bloat

Поиск
Список
Период
Сортировка
От The Hermit Hacker
Тема Re: database file size bloat
Дата
Msg-id Pine.BSF.4.21.0004141447120.2807-100000@thelab.hub.org
обсуждение исходный текст
Ответ на Re: database file size bloat  (Brian Neal <aceface@bellsouth.net>)
Ответы Re: database file size bloat  (Marten Feldtmann <marten@feki.toppoint.de>)
Список pgsql-general
On Fri, 14 Apr 2000, Brian Neal wrote:

>
> Maybe you might want to try out MySQL?  A little while ago, I compared
> both MySQL and PostgreSQL to see how they stacked up (for my purposes,
> anyway).  I came to the conclusion that while MySQL is a very fast
> read-only database, it doesn't support transactions, row-level locks,
> stored-procedures, sub-selects, etc.  PostgreSQL has a lot more basic
> database support, but it is harder to install and maintain (in my
> opinion), has worse documentation, and a number of interesting
> quirks...for example, the fixed-size row limitation that can only be
> changed by a recompilation, or the VACUUM problem described here.
> Other issues I had included the way the backend seemed to work...it is
> certainly very demanding when it comes to shared memory, and I had
> concerns about the process pool (whether or not pg-sql could handle
> enough connections) instead of threads, which most other databases
> seem to use.

Few commments ... the 'row size limit' should be gone in v7.1, as Jan is
working on implementing TOAST for that ...

AS for the process pool ... there are two camps here ... if you use
threads, when one threads crashes the server, the server is done.  With
forking,if one backend dies, the server is still running ... in a 24x7
shop, I'd rather the solution that doesn't die cause JoeBlow down the hall
blew out something with his query :)



В списке pgsql-general по дате отправления:

Предыдущее
От: Leitor de Listas
Дата:
Сообщение: PRIMARY KEY
Следующее
От: Haroldo Stenger
Дата:
Сообщение: Does error within transaction imply restarting it?