Re: Perceived weaknesses of postgres

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

In response to

Responses

Browse pgsql-general by date

  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