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 по дате отправления: