From: | Magnus Hagander <magnus(at)hagander(dot)net> |
---|---|
To: | Dawid Kuroczko <qnex42(at)gmail(dot)com> |
Cc: | Csaba Nagy <nagy(at)ecircle-ag(dot)com>, Postgres general mailing list <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Perceived weaknesses of postgres |
Date: | 2008-02-13 12:56:28 |
Message-ID: | 47B2E8FC.3010801@hagander.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Dawid Kuroczko wrote:
> On Feb 13, 2008 10:49 AM, Csaba Nagy <nagy(at)ecircle-ag(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Tino Wildenhain | 2008-02-13 13:04:43 | Re: dynamic crosstab |
Previous Message | Tino Wildenhain | 2008-02-13 12:51:26 | Re: Perceived weaknesses of postgres |