Re: Limitations of PostgreSQL

From: Chris Travers <chris(at)travelamericas(dot)com>
To: Scott Marlowe <smarlowe(at)g2switchworks(dot)com>
Cc: Chris Travers <chris(at)travelamericas(dot)com>, Denis G Dudhia <denu79(at)rediffmail(dot)com>, pgsql-general <pgsql-general(at)postgresql(dot)org>
Subject: Re: Limitations of PostgreSQL
Date: 2005-10-13 04:11:53
Message-ID: 434DDE89.8040800@travelamericas.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe wrote:

>On Wed, 2005-10-12 at 16:16, Chris Travers wrote:
>
>
>>Denis G Dudhia wrote:
>>
>>
>>
>>>Hello There...
>>>
>>>I am new to PostgreSQL.
>>>
>>>I usually check out negative sides of any software or system, before
>>>implementing it or using it.
>>>
>>>
>>>
>>Compared to MySQL, I can't think of any downsides. All relevant
>>usability issues have been solved, though there are some functions like
>>INTERVAL that are not supported (see my migration guide at
>>http://www.metatrontech.com/wpapers/)
>>
>>
>
>What, exactly, is the interval function in MySQL? IS that one that
>creates a sequence of numbers or whatnot? If so, there is an equivalent
>in 8.0 now. By the way, interval is a SQL reserved keyword, so it's
>surprising MySQL would choose to name a function after it.
>
>
>
It is sort of like LEAST and GREATEST but somewhat different....

For example, INTERVAL(45, 0, 20, 40, 80, 100) will return 3 (I think)
because 45 is between 40 and 80.

I don't know if it is specified in the standard or not or even if it is
useful. Just thought I would mention it.

>Thought I'd comment on this.
>
>According to the author of the innodb engine, innodb uses MVCC.
>OTOH, I consider innodb to be broken in production, due to issues with
>constant growth and no way to reclaim the lost space.
>
>
Any sources on that? I would love to have info on that.

>This means that vacuuming, a minor annoyance in PostgreSQL, is a major
>issue for 24/7 mysql databases running on innodb, where they must be
>shut down and restarted to clear up the unused space in the innodb
>tablespace.
>
>
>
>
No kidding. Would like more info.

>>Multimaster async replication w/updates is a pain at the moment and
>>mostly a set of kludges.
>>
>>
>
>There really are too many use cases for there to be a "simple"
>resolution to the problems presented by multi-master replication. It's
>a complex problem that creates more complex problems as you attempt to
>solve it.
>
>
I have come up with some ways of doing this but they are difficult. And
the question is always "How good is good enough"

>
>
>>I am not aware of any good sync. replication solutions for PostgreSQL at
>>the moment.
>>
>>
>
>pgpool does a good job. Many folks miss the fact that it can do
>replication as well as load balancing. pgcluster uses parts of pgpool
>to do its clustering as well. They are, however, statement level, not
>log level.
>
>
I will remember that.

>
>
>>Does not have full XA support at the moment (does have TPC).
>>
>>
>
>I'd point out here that MySQL's XA support is quite primitive, and only
>useful for a fairly smaller number of cases.
>
>
Again, I was comparing with DB2 and Oracle. One should consider all new
features of MySQL to be both overmarketed and primitive for some time.

Best Wishes,
Chris Travers
Metatron Technology Consulting

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Joshua D. Drake 2005-10-13 04:25:41 Re: PG 8.0.4, Centos and 64 bit
Previous Message Marc G. Fournier 2005-10-13 03:57:39 8.1 Beta 3: The Final Beta?