Re: [HACKERS] [OT] MySQL is bad, but THIS bad?
Jim C. Nasby
On Thu, May 18, 2006 at 11:32:30AM -0700, Joshua D. Drake wrote:
>
> >And MySQL is much closer to being a competitor now than they were in
> >4.1. And feature-wise they'll probably equal PostgreSQL in the next
> >release. Will the features be anywhere near as robust or well thought
> >out? No. But in a heck of a lot of companies that doesn't matter.
>
> Your kidding right? Have you seen their "features"? Look at what their
> stored procedures are actually capable of.
But it doesn't really matter from a marketing standpoint how badly the
feature sucks, so long as it's there. And if you want to believe the
marketing, they're actually more advanced than us, with "features" such
as replication and clustering.
> The only thing that MySQL *might* pull off is a really good storage
> backend finally.
>
> >Maybe a compatability layer isn't worth doing, but I certainly think
> >it's very much worthwhile for the community to do everything possible to
> >encourage migration from MySQL. We should be able to lay claim to most
> >advanced and most popular OSS database.
>
> Oh absolutely, I agree with you here but in order to do so in the most
> productive manner possible the community would have to be willing to be
> much more aggressive and much more antagnositic that I believe the
> community has the stomach for.
I don't think it has to necessarily be antagonistic. Simply looking at
how these features compare would probably shed a lot of light.
BTW, should anyone want to undertake some writing along these lines,
Pervasive will probably pay for it, depending on what exactly the topic
is:
http://www.pervasivepostgres.com/postgresql/partners_in_publishing.asp
--
Jim C. Nasby, Sr. Engineering Consultant jna...@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster
Jim C. Nasby
On Fri, May 19, 2006 at 08:11:42AM -0700, Joshua D. Drake wrote:
> When MySQL is at that
> >point, which database do you think executives will be choosing? The one
> >with a very large userbase and lots of marketing and PR that they've
> >heard plenty about,
>
> All due respect, Jim -- but don't you work for a publicly traded
> database company that happens to have its own version of PostgreSQL?
Actually, we haven't had a distribution of PostgreSQL since 8.0.3, and
even then it was only a distribution; the bits were all community.
> This is really a discussion for your marketing (and mine frankly) then
> the PostgreSQL mailing lists :)
Yes and no... should MySQL eventually become popular enough that there's
little use of PostgreSQL that hurts the community just as much as it
hurts our companies. In fact, I'd say it's already hurting the community
more than our companies; look at how many people lament about running
software XYZ because it only supports MySQL. Or about trying to find
PostgreSQL hosting providers.
But yes, the group of PostgreSQL companies should also be working to
raise awareness of PostgreSQL as a very viable OSS database.
Unfortunately, a lot of the commercial interest is in the higher-end
market. And to a large extent, this really needs to be a grass-roots
effort. After all, you don't win OSS mindshare by taking out ads or
anything like that. So I think this really needs to be a joint venture
between companies and the community.
--
Jim C. Nasby, Sr. Engineering Consultant jna...@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?
Bruce Momjian
> Yes and no... should MySQL eventually become popular enough that there's
> little use of PostgreSQL that hurts the community just as much as it
> hurts our companies. In fact, I'd say it's already hurting the community
> more than our companies; look at how many people lament about running
> software XYZ because it only supports MySQL. Or about trying to find
> PostgreSQL hosting providers.
With Linux, it was open for developers to join in, and that fueled its
growth. In fact, some say Linux gained only because it was more open
the *BSD. Fortunately for us, MySQL foster open development, which
means they will never catch us in the long run.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
Joshua D. Drake
> Jim C. Nasby wrote:
>> Yes and no... should MySQL eventually become popular enough that there's
>> little use of PostgreSQL that hurts the community just as much as it
>> hurts our companies. In fact, I'd say it's already hurting the community
>> more than our companies; look at how many people lament about running
>> software XYZ because it only supports MySQL. Or about trying to find
>> PostgreSQL hosting providers.
>
> With Linux, it was open for developers to join in, and that fueled its
> growth. In fact, some say Linux gained only because it was more open
> the *BSD.
I would agree with this. BSD at one time made Linux look like a toy. If
the *core* of the BSD teams would have been more open in there
development, linux would probably be relegated to also ran status.
Fortunately for us, MySQL foster open development, which
> means they will never catch us in the long run.
>
--
=== The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
Providing the most comprehensive PostgreSQL solutions since 1997
http://www.commandprompt.com/
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
Bruce Momjian
> > means they will never catch us in the long run.
Sorry, I meant to say:
Fortunately for us, MySQL _do_ _not_ foster open development, which
means they will never catch us in the long run.
--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +
---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings
Dawid Kuroczko
> The improvements to the installer are great, but there simply needs to
> be a packaged solution that adds more of the things people are very
> likely to use. From my understanding Bizgres goes in that direction? I
> just think that whatever highly packaged solution PostgreSQL picks, this
> should be the download that is pushed at conferences, in articles and
> books. People with a clue will still know where they can get the clean base.
Hmm, a Comprehensive PostgreSQL Archive Network? ;)
I mean, something like CPAN, CTAN or CRAN? :)
I mean, the -contrib is great, but pushing other things there is a bit
tricky (to say the least) from the maintenance point of view. (Every
bugfix, a new release of -contrib, etc, etc...).
Then again PGfoundry is great to keep development centered, but
finding and building a new package is not really a one-liner, and
if you're unlucky you might get alpha-quality code installed. :)
I think a CPgAN-like solution would be the best. A uniform method
of getting approved Pg extensions. It would simplify installing the
extensions, and would encourage distributions to package such
extensions. Somebody suggested apt-get install postgresql-contrib.
Imagine:
apt-get install postgresql-datatype-fqdn
apt-get install postgresql-gist-ltree
...and so on.
Regards,
Dawid
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
Joshua D. Drake
>
> Then again PGfoundry is great to keep development centered, but
> finding and building a new package is not really a one-liner, and
> if you're unlucky you might get alpha-quality code installed. :)
>
(www.mammothpostgresql.org) that is designed to be a COMPLETE postgresql
distribution.
Joshua D. Drake
Jim C. Nasby
> On 5/20/06, Lukas Smith <sm...@pooteeweet.org> wrote:
> >The improvements to the installer are great, but there simply needs to
> >be a packaged solution that adds more of the things people are very
> >likely to use. From my understanding Bizgres goes in that direction? I
> >just think that whatever highly packaged solution PostgreSQL picks, this
> >should be the download that is pushed at conferences, in articles and
> >books. People with a clue will still know where they can get the clean
> >base.
>
> Hmm, a Comprehensive PostgreSQL Archive Network? ;)
>
> I mean, something like CPAN, CTAN or CRAN? :)
>
> I mean, the -contrib is great, but pushing other things there is a bit
> tricky (to say the least) from the maintenance point of view. (Every
> bugfix, a new release of -contrib, etc, etc...).
>
> Then again PGfoundry is great to keep development centered, but
> finding and building a new package is not really a one-liner, and
> if you're unlucky you might get alpha-quality code installed. :)
In fact, my thought was that any such system should use pgFoundry as
it's backend/repository.
> I think a CPgAN-like solution would be the best. A uniform method
> of getting approved Pg extensions. It would simplify installing the
> extensions, and would encourage distributions to package such
> extensions. Somebody suggested apt-get install postgresql-contrib.
> Imagine:
> apt-get install postgresql-datatype-fqdn
> apt-get install postgresql-gist-ltree
> ...and so on.
Except that apt doesn't work on all platforms. Though it would certainly
make sense to look at lifting the framework for CPgAN from somewhere,
rather than coding it ourselves.
--
Jim C. Nasby, Sr. Engineering Consultant jna...@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
---------------------------(end of broadcast)---------------------------
Dawid Kuroczko
> > Except that apt doesn't work on all platforms. Though it would certainly
> > make sense to look at lifting the framework for CPgAN from somewhere,
> > rather than coding it ourselves.
>
>
> As a software developer, I'm fine with pgfoundery, but as a DB admin, and
> one who deploys data centers from time to time, I'd like to see something
> closer to the contrib.
>
> If I could have any influence at all, I'd like to see "contrib"
> essentially go away in the main distribution and replaced or renamed
> "extensions." Then, some advisory group "blesses" extensions, and those
> extensions get packaged into a PostgreSQL extensions pack. I, again as a
> DB admin, would have NO problem with PostgreSQL playing favorites and
> picking best of breed for these extensions.
The "problem" with contrib is that no actively developed projects should
be there. It is a feature, not a bug. If it is actively developed, it may be
buggy. If it is proven over time, it can be safely used. Also, for a contrib
it is inefficient to release a whole -contrib whenever a subproject releases
new release. This "forces" -contrib to use stable-and-unchanging packages.
This also makes it extremaly hard to put new or niche projects. New are
risky, because they may need immediate bugfixes. Niche projects used
by a minority of users bloat -contrib and force more frequent releases,
both of which are well, not preferred.
Of course -contrib is great, we all know it. I think a "CPgAN" would be
a good testbed/incubator for new packages, some of which should
eventually get into -contrib.
Also, assuming there is a "pginstall dbanme packagename" interface,
a -contrib package should register all its subpackages within that
system. So, you install postgresql-contrib, and then you can type:
pg_package install mydb index/ltree
and later, provided you change your mind:
pg_package remove mydb index/ltree
(with -f option to "insert CASCADE whenever possible ;)).
This would be somewhat similar to current createlang(1) and friends. :)
Regards,
Dawid
---------------------------(end of broadcast)---------------------------