Re: Perceived weaknesses of postgres

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. ;-)))

> * 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. :)

> * no direct table cache control;

Could you elaborate more on this one?

> * accent-insensitive text comparisons;

Yesss. That would be quite useful. A more generic problem would be multiple
collations in one cluster. Hopefully at column level.

> * fast select count(*);
> Wrong assumptions (but people seem to be sure it's like this):
> * no hotbackup except pg_dump (wrong: there are in fact a few different
> ways to do that);

...and pg_dump is not exactly hot. And PITR using log archiving is a
great thing.
I've set up a backups using Tivoli Storage Manager, and it works quite fine.

BTW there is an urban legend, that Oracle stops writing to its datafiles
when you ALTER TABLESPACE into backup mode. This is not true,
they are modifying the files quite same as we do. :-)

> * 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...).

This could be solved with help of DDL/DCL triggers though, which
would be helpful for other things too, I guess.

> * missing 2 phase commit (wrong: it is now implemented);
> * inadequate performance with really large databases (wrong: there are
> known examples of really large postgres DBs);
>
> There are other claims like (quoting): "RAC, enterprise backup
> capabilities, database on raw partition, compatibility with enterprise
> storage (SAN,...)" which I don't know if there are adequate solutions
> for postgres or not.

Regards,
Dawid