Re: Limitations of PostgreSQL

Поиск
Список
Период
Сортировка
От Chris Travers
Тема Re: Limitations of PostgreSQL
Дата
Msg-id 434DDE89.8040800@travelamericas.com
обсуждение исходный текст
Ответ на Re: Limitations of PostgreSQL  (Scott Marlowe <smarlowe@g2switchworks.com>)
Ответы Re: Limitations of PostgreSQL  (Scott Marlowe <smarlowe@g2switchworks.com>)
Список 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

В списке pgsql-general по дате отправления:

Предыдущее
От: Tony Caduto
Дата:
Сообщение: Re: PG 8.0.4, Centos and 64 bit
Следующее
От: "Joshua D. Drake"
Дата:
Сообщение: Re: PG 8.0.4, Centos and 64 bit