Re: Perceived weaknesses of postgres
От | Magnus Hagander |
---|---|
Тема | Re: Perceived weaknesses of postgres |
Дата | |
Msg-id | 47B2E8FC.3010801@hagander.net обсуждение исходный текст |
Ответ на | Re: Perceived weaknesses of postgres ("Dawid Kuroczko" <qnex42@gmail.com>) |
Ответы |
Re: Perceived weaknesses of postgres
Re: Perceived weaknesses of postgres |
Список | pgsql-general |
Dawid Kuroczko wrote: > On Feb 13, 2008 10:49 AM, Csaba Nagy <nagy@ecircle-ag.com> wrote: >> http://www.theserverside.com/news/thread.tss?thread_id=48339 >> >> The interesting part is where somebody asks why NOT use postgres, and >> it's answers could give some additional hints to those interested on >> what people find missing from postgres to adopt it. >> >> Just to summarize some of the answers: >> * major PITA to upgrade between major versions; > > Would be nice, though I must say that while the data migration is a pain, the > SQL compatibility PostgreSQL provides is a blessing. Other open source > RDBMS have major PITA changing queries in applications. ;-))) I don't think these people are comparing to other opensource ones... They're comparing to the commercial ones (at least in this case) >> * executing a single query on multiple cpus/cores; > > I wonder if our most popular open source rival can do it. I have > heard people claiming > so but I would not consider them authoritative. :) Again, the commercial ones do, and that's what we're compared to... >> * no direct table cache control; > > Could you elaborate more on this one? I would guess they're referring to the ability to "pin" a table into memory, so that it always stays in the cache regardless of what else the database is doing. There is a narrow use-case where this can be very useful, but it can also be a very dangerous tool (hint: if you pin a table that grows up to say 80-90% of your RAM size, your database will not be fast for anything else) >> * pg_dump the only way to cleanly upgrade (wrong: slony is good for >> that); > > Slony is good as long as there are no DDLs issued. And its easy to > shoot oneself in the foot if one is not careful (some time ago I have > lost all the triggers while upgrading from 8.1 to 8.2; it was my fault > since I did pg_dump -s on a slave database, not on the master...). You can do DDL with Slony, but it requires some planning (DDLSCRIPT). Doesn't solve all problems, but it does solve some. //Magnus
В списке pgsql-general по дате отправления: