Thread: [pgsql-advocacy] eWeek Poll: Which database is most critical to your organization?
[pgsql-advocacy] eWeek Poll: Which database is most critical to your organization?
From
Zak Greant
Date:
Good Day All, eWeek has posted a poll that asks which database server is most critical to your organization. The poll tracks the following databases: - IBM DB2 - Informix - Microsoft SQL Server - MySQL - Ingres - Oracle - PostgreSQL - Sybase Adaptive Server Enterprise - Sybase SQL Anywhere - any object database It is interesting to note that Oracle has shown a rather large jump between yesterday and today - about 7% IIRC - a sign that the sample size of the poll should become larger. :) If you would care to vote, visit: http://www.eweek.com/article/0%2c3658%2cs=708&a=23115%2c00.asp Note: This message is being delivered to the Perl DBI, PHP general, PostgreSQL Advocacy, MySQL general and Ruby general mailing lists. However, to prevent possible and irritating cross-posting, I am delivering each message individually. :) Ciao! --zak -- __ ___ ___ ____ __ / |/ /_ __/ __/ __ \/ / Zak Greant <zak@mysql.com> / /|_/ / // /\ \/ /_/ / /__ MySQL AB, Advocate /_/ /_/\_, /___/\___\_\___/ Calgary, Canada <___/ www.mysql.com 403.244.7213 ---------------------------(end of broadcast)--------------------------- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
On Tue, 2002-02-26 at 15:30, Zak Greant wrote: > Good Day All, > > eWeek has posted a poll that asks which database server is most critical > to your organization. The article mentions a MySQL feature which apparently improved performance considerably: // MySQL 4.0.1's new, extremely fast query cache is also quite notable, as no other database we tested had this feature. If the text of an incoming query has a byte-for-byte match with a cached query, MySQL can retrieve the results directly from the cache without compiling the query, getting locks or doing index accesses. This query caching will be effective only for tables with few updates because any table updates that clear the cache to guarantee correct results are always returned. // My guess is that it would be relatively simple to implement. Any comments on this? If I implemented this, any chance this would make it into the tree? Of course, it would be: - disabled by default - enabled on a table-by-table basis (maybe an ALTER TABLE command) Cheers, Neil -- Neil Conway <neilconway@rogers.com> PGP Key ID: DB3C29FC
Neil Conway wrote: > > On Tue, 2002-02-26 at 15:30, Zak Greant wrote: > > Good Day All, > > > > eWeek has posted a poll that asks which database server is most critical > > to your organization. > > The article mentions a MySQL feature which apparently improved > performance considerably: > > // > MySQL 4.0.1's new, extremely fast query cache is also quite notable, as > no other database we tested had this feature. Hmm is it really a notable feature ? IIRC Oracle has had a similar feature for a long time. regards, Hiroshi Inoue
Hannu Krosing wrote: > > On Wed, 2002-02-27 at 11:44, Hiroshi Inoue wrote: > > Neil Conway wrote: > > > // > > > MySQL 4.0.1's new, extremely fast query cache is also quite notable, as > > > no other database we tested had this feature. > > > > Hmm is it really a notable feature ? > > It makes a powerful database eqally fast to not-so-powerful one for > simple cases. Sorry I may be misunderstanding your point. What I meant was it's not a notably new feature and I love the feature itself. regards, Hiroshi Inoue
On Wed, 2002-02-27 at 11:44, Hiroshi Inoue wrote: > Neil Conway wrote: > > // > > MySQL 4.0.1's new, extremely fast query cache is also quite notable, as > > no other database we tested had this feature. > > Hmm is it really a notable feature ? It makes a powerful database eqally fast to not-so-powerful one for simple cases. > IIRC Oracle has had a similar feature for a long time. I guess that's for exactly this reason :) --------- Hannu