| 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: | Whole Thread | Raw Message | 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
| 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? |