Postgresql is still not quite as fast (in my experience) as MySQL, but the comparison is not fair due to MySQL's lack of features.
Well, for single user experiences, MySQL probably is faster. PostgreSQL tends to scale much, much better than MySQL. In other words, if you have a DB where you expect to have lots of active users with a diverse set of concurrent activity (selects, updates, inserts, deletes), PostgreSQL traditionally zooms way ahead of MySQL. It's a question of how you expect to use your database.
Basically, it's a myth that MySQL is faster than PostgreSQL. A myth, I might add, which MySQL themselves help propagate. Simple fact is, MySQL probably is faster in the developer's eyes. Once it's deployed, PostgreSQL is more than likely the faster of the two. Granted, there are some corner cases where MySQL is still faster than PostgreSQL, but those are the exceptions and NOT the rule.
PostgreSQL got significantly faster in the 7.x release series. With the up coming release of 8.x series, it recieved another signifnicant boost in performance.
The 6.x series was known to be slow. That is very much a thing of the past.
It appears he's even gone beyond the scope of the GPL by offering to replace code written by folks who don't like what he's doing.
How is that BEYOND the GPL? He's using GPL code in his own product that he is selling and the code is NOT available. He is NOT going above and beyond the GPL. He's yet to be meet the letter of the law. Besides, once he offers an application for distriubtion, ALL of his code became GPL. This means, 100% of the code that he uses to build his shareware version is absoluetely, 100%, GPL now.
It's just a matter of shaking the tree hard enough to get this theif to do what the law requires.
No, they didn't specify a license. This is the whole problem.
Actually, they did specify a license. They contributed under the banner of the GPL license. If the project, at the time, had been the BSD license, then the code would of been BSD. Period. The courts are very clear on this. This is cut and dry.
We may assume they intended to license the code under the GPL, but in order to do that you need to _specifically state_ that you are licensing under those terms. They probably didn't.
Not only is this wrong, but the GPL even makes it easier. The second that a release was made with that contributed code, the code was reaffirmed as being GPL licensed. Period. There is no gray area here. ALL of the contributed code is GPL. Period. No then, if he has explicit permission from each contributor to relicense their code, or explicit wording whereby, they render their copyright, ONLY THEN is he in the clear. Until he can prove that such information exists, he is 100%, cut and dry, in violation of the GPL. AND his current closed source product IS a GPL product. Period. Cut and dry.
In otherwords, the burden of proof falls squarely on his shoulders. Until he can prove that the code is NOT strictly GPL or that he owns all of the copyrights, he is in violation of the GPL. Period.
Your assumption about the contributed code being under the GPL is not necessarily clear cut, though probably correct.
Actually, it is very clear cut. Because it's so clear cut, requiring people to assign copyright or provide a pertetual license is the STANDARD remedy to prevent this whole situation.
On the other hand, those contributing probably didn't specify the license they were licensing the code back to him under.
It's not like there is a grey area here. ALL of the contributed code was contributed under the GPL license. No one needs to state what license it's being contributed under because everyone already knows and understands that it's GPL. Period.
It's because of this that ALL of his current code is now GPL. He is attempting to create a closed source product out of GPL code. The GPL is very explicit about this.
The GPL sets the terms under which you can do some things that copyright law normally doesn't let you do.... period.
Agreed, however, there actually are suits by proxy. In most cases, it becomes problematic to execute. In this case, since it's for the common good (the populas) rather than a single company or person, it becomes must easier to execute. After all, the contributed code IS licensed for EVERYONE to consume. This idiot is not preventing everyone from getting their share of the code. Courts are setup to handle this class of problem. It's just traditionally problematic. The only question is, will the FSF step in. Traditionally they won't unless one or more of the authors turn over their copyright. And, I can't blame them because they have finite resources and it makes it meach, much easier and faster.
In this case, from what I can gather, he has CLEAR GPL code being compiled and linked with his non-GPL application. Furthermore, he appears to even admit this, simply stating, on request from a specific section of code's author, the offending code will be removed. Basically, he understands that he's using GPL code and doesn't care. I can't wait for him to get the GPL shoved up his tail pipe. This type of theft is exactly what the GPL attempts to prevent.
You're showing that you're clueless. Zero people have to object to this. Read this clearly. I'll say it again. ZERO PEOPLE HAVE TO OBJECT TO THIS!!! The contributed code was contributed while under the GPL license. That means, the code is GPL!!! Period. I'll say it again, some of the code, even AFTER he dual licensed his code, is GPL code. That means, ALL of the code is NOW GPL, regardless of what his obviously illegal intention was. Period. Because he embeded GPL code into an application, which does not fall under the GPL, his application and associated code is now, 100% GPL. Period. He must now release his code. Period. Unless he can PROVE that people assigned copyright for their contributions to him, he is using GPL code. We all know what that means. In plain English, that means he's trying to be a scumbag theif, knowing full well, that he's stealing GPL code.
There was ONLY two ways to interpret what he's done. One, he's a crook, stealing other people's GPL code. Two, He's a crook, stealing other people's GPL code.
All of the code which he wrote for the windows "shareware" version of X-Chat is now 100% GPL. Period. He is in violation of the GPL license AND in violation of ALL of the contributor's copyrights. Period. At this point in time, his only option is to provide the code which is GPL. That means, ALL of the GPL code. That means, ALL of the code. Period.
If he wanted to avoid all of this, he should of made people sign away their copyright before he would officially add in their submitted code. Or, it should of made it clear that he desired a perpetual license to their contributed works, whereby, he's free to relicense at will. Since he didn't do this, he is illegally embedding GPL code into his non-GPL's licensed product. That means, the instant that he made a distribution of his application available for public consumption, all of the associated works became GPL. Period. End of discussion. He KNEW full well, what he was doing and decided that he had the right to steal. The GPL is specifically set up to catch scum-bags like this.
That's 100% wrong. They did specify a license. The donated code under the presumption that the license was GPL. He has zero right to change THEIR licensing agreement. He's completely screwed up here. He wrote some of his own code which he did not want to release. He released it KNOWING FULL WELL THAT IT'S TIED TO GPL CODE. This means that all of his "secret code stash" is now GPL too. He's an idiot. In the attached letter, he even admits that he knows and UNDERSTANDS that the code was contributed under a GPL license. He would have to be an idiot to not know this. Instead of doing the right thing, he simply steals the code and says he'll take it out if someone objects.
He is ABSOLUTELY in violation of the GPL. Period. End fo discussion. You write an application which you knowingly embed GPL code into, your application and all assocaited code, up to and including what you last released, is not 100% GPL. Period. This is EXACTLY what this idiot did. The GPL is VERY explicit about this type of stealing. It's very cut and dry. He's stealing someone else's copyrighted works OR is in violation of the GPL. There is VERY simple to understand.
In a nutshell, he's an idiot. An idiot, which I might add, is in violation of the GPL.
First, great email to this guy. To bad he's too stupid to understand his own situation.
Well, his problem is, people contributed code under the understanding that it was the GPL license. For him to relicense their code, to which he has no copyright, is in error. Bluntly, he in in violation of everyone that has previously contributed code. He can attempt to dance around that fact, but he has two choices at this point in time. One, immediately remove ALL code contributed by all other authors or immediately release all of his current code under the terms of the GPL. Period. He has no other options. If he decides to remove ALL contriubted code, then and ONLY then can he continue down his desired dual license path. The only other chance he has is to obtain copyright from all contributed authors. Until such time, any code which he has written, which uses the strictly GPL (3rd party) contributed code, is tainted by the GPL. That means, once he made available, for release, code which was ONLY licensed under the GPL, all of his new code is ALSO licensed under the GPL.
Strictly stated, no matter what he thinks, he is absoluetely in violation of the GPL. Once he either rips out all of the contriubted code or obtains additional licensing rights, only then would he be free to create a non-GPL binary and still be compliant with the terms of the GPL. In the meantime, he distributed code which is directly tied to GPL code. In otherwords, ALL of the code, up to the point which he last distributed it, must immediately be made available AND licenesed under the terms of the GPL.
Bluntly, he has no choice but to release his modified code. Period. Once he obtains his ownership and/or relicenses the copyrighted works which were contributed by other authors, only then can he do what he's wanting to do. This is EXACLY why the GPL is in place. It's designed to stop crooks like him.
He's getting ready to get spanked hard if he doesn't quickly remove his head from his tail pipe. Bluntly, I havea hard time imagining a bigger idiot.
Go back and re-read what I said. That alone, is not a huge improvement. A minor improvement with a huge improvement to our ecology is. Together, it's simply awesome.
Until you consider the environmental impact, then it's suddenly a HUGE improvement, with higher effeciency to boot. Right now, people would kill people to have the solution you're turning your nose up at.
From what I understand, hemp would be a great replacement here. Supposedly, it can be harvested 4x more often than corn for ethanol production AND does not require fertilizer or pesticides, which further makes hemp cheaper to grow and harvest, with fewer environmental sie effects. In other words, it's supposed to be more than 4x cheaper (energy wise) to convert hemp into ethanol than corn.
Of course there's this little political problem...
Ya, the political problem is from the oil and chemical companies. Seems that hemp has little to no active ingrediants that are associated with pot, making it a safe commercial crop. Which, I might add, is contrary to what is commonly taught. Accordingly, the reason hemp was outlawed had nothing to do with pot or drug concerns (though that thinking was illogically encouraged), but rather because of lobbying by oil and chemical companies. Seems oil and chemical companies needed a market for their new found abilities to create plastics, nylon, and other artificial fibers, all of which directly compete with hemp.
Your admittedly technologically cool solution is addressing needs of maybe 5% of users leaving the majority out in the cold.
Well, I'm not sure it's right to call it "mine".;) Tom is a purist and frankly, it's annoying form time to time. There are times when, as we both see, purity gets in the way of good business sense. But (you knew it was coming), many features which get added (by developres, do make use of these facilities, so it's not really fair to to call Tom out either. He's a smart guy and often sees the whole picture bigger and better then most. Then there are those times when you just want to smack him up side his head.;) But that doesn't happen very often.
I don't exppect to run maintanence jobs (VACUUM) every hour during peak load times becuase otherwise the database does not perform.
In fairness, you haven't had to for a while now, thanks to the AVD. Also worth mentioning is that 8.0 brings new optimizations which will further reduce disk spikes during WAL flush as well as reduce disk spike and CPU hits from vacuumes. Both of which, seemingly are targeted to make YOU happy.;)
Re-read your words. What you are describing is exactly the steep learning curve: a simple thing requiring a complex solution. Is it not? What about porting issues? Just think about how much effort is wasted by reimplementing every simple query with triggers.
Ya, I thought you might say this. Put it into perspective. Look at the odd contortions that people have to go through with MySQL to do some things, which are trivial on most every other RDBMS. Yet, people still consider MySQL to very simple. And, let's not lose perspective here. It's not like you have to "reimplement every simple query with triggers." That's simply not a fair or honest statement. For smaller tables, use select count(*). For large targets and larger, compute the derived value via a trigger. Which, suddenly makes your select run as fast or faster than most other systems. It's not like select count(*) has to be ruled out completely. But, I clearly see your point and agree somewhere in the middle, somewhat.
Less than MSSQL - no. But that could be just our shop since we have the people with the right experience.
I'd place my money on having the experience. Look at how many versions and how incrementally MSSQL knowledge has been gained. You can't dismiss it and it's certainly not fair to compair years of experience and expertise with zero on a new RDBMS and say one complex and the other is not. Realistically, MSSQL has continued to add many complex and powerful features. It's no longer the trivially easy DB that it was 6 years ago. Likewise, you've learned what and how to do things and what things to avoid. You know how to tune it and it's part of your "trivial" knowledge now. As such, it's not fair to compare the two using such a metric. As I said, each system has their own quirks and caveats, it's just that you have mastered them on MSSQL.
The show stopper was a table with the market data. It had the bars with Open/High/Low/Close. It had about 20 columns, about 5-10 million records for a total 1-1.5GB.
Were all 20 columns commonly queried? If not, paritioning your data may make sense. With tablespaces (versus the old voodoo method), you will be able to more readily spread your disk activity out, which will also greatly help your performance (e.g. index on one disk, WAL on another, table on yet another). Without knowing the details, I'm betting there's a number of optimizations which are available, even with the current stable release (7.4.2, with 7.4.3 or 7.4.4 due out shortly).
The whole table was never kept in RAM, although the RAM was sufficient. The relatively rare queries for historic data trashed the cache, so selects for recent data had to refill it from disk.
Sounds like the need for additional tuning. On a dedicated server, the OS sho
Absoluetely not. There is nothing wrong with it. It's just the developers don't want to have to hard code an optimal path for that aggregate. The issue exists because PostgreSQL supports user extensible aggregate functions, whereas most DB's don't.
PgSQL is difficult because it has unusual problems, not expected from experience with Oracle/MSSQL/MySQQL
Well, that I'm not willing to swallow. Simple fact is, each and every RDBMS has their own distinct sets of issues, problems, caveats. If something as simple as "select count(*)" is a serious problem, then chances are, you shouldn't be using a database to begin with. While clearly more cumbersome, triggers are easily implemented which allow you to easily and rapidly store derived values, such as counts. This is a very, very minor work around compared what things that MySQL forces people to do. The primary difference is that most people don't realize they they are doing things they hardway with MySQL until they get experience on other systems.
As for aggregates, I know PgSQL functions can't use indexes by design.
I'm not sure we're talking about the same thing here, but PostgreSQL has allowed functional indexes for some time now. But I don't think it would make sense to think that you can create a functional index on an aggregate. I think they were introduced in 7.1 or 7.2. Here's a reference to the 7.2 docs which talk about it.
One quite capable DB admin worked on it full time for about two weeks, another one consulted. They tried everything imaginable. Still, running vacuum slowed selects by 5-10 times. That was not acceptable during the day, thus we could run it only at night. And that was not often enough.
I certainly don't mean to knock your DBAs. My point is, did they attempt to get support from the mailing lists? Did they use the available documentation to it's fullest? Thinking that a Sybase DBA is going make an Oracle database sing, without Oracle DBAs helping, isn't very realistic. That's my point. Far too often, I see people state that they had problems, usually very, very basic problems, but never once bothered to get help from the people that are most qualified to help. Whos failing is that? PostgreSQL's or the DBA's? Obviously, I can't comment on the specifics here, but I think you can understand where I'm coming from.
Yes, you can say they were not experienced enough. I can also say that the configuration was overly difficult.
Well, I certainly do believe that there is a learning curve. You'll find that any non-trivial RDBMS has such a curve. IMO, PostgreSQL is no greater than any other. In fact, I would argue that it's certainly far less steep than Oracle or MSSQL. Having said that, just because there is a curve, is not an excuse (making an assumption here) to not obtain assistance from the wonderful support mechanisms which are readily available to any PostgreSQL user.
I mean a dedicated server, as in nothing but PgSQL 7.4 on a FreeBSD 4.9. Say, the DB is 1GB, server has 2GB RAM. PgSQL should just suck everything in RAM and run read queries directly from there. Why can't it do it? Or maybe it can, but how to configure it in such a way is really non-obvious.
Well, unlike most DB's, PostgreSQL assumes that the OS will do a fair share of caching. This means, you want to leave a fair amount free for system cache. Having said that, for the internal buffers that PostgreSQL does keep, version 8.0 does add several optimizations which greatly enhances many types of workloads (seq scan no longer flushes buffers of commonly used rows, etc).
Many more specifics can easily be gained from reading the documentation, reading the easy to follow tuning guide, which I previously pointed people at, or heck, either doing simple searches of the archives or simply posting a question to a ma
PgSQL had a very steep lerning curve even for people with experience in other databases. Various unusual stuff just popped up in places which could notbe expected from previous experience elsewhere.
IMO, it has a "very steep" learning curve because so many people have to unlearn all the bad habbits from MySQL. If you're coming to PostgreSQL, and can be bothered to read and follow directions for 30-minutes to an hour, IMO, you'll be on the same footing. In my opinion, the there is a curve, but it's not steep at all, assuming you're not coming from MySQL, where you've been taught to do things counter to just about every other product out there.
How about COUNT(*) and other aggregates?
That's a great question! Sadly, select count(*) is still slow and don't imagine that changing any time soon, at all. Many other aggregates are now faster. These are incremental changes that have been creaping in over the last four of fives releases. Aside from select count(*), PostgreSQL offers a very speedy solution. The general run is, if you really need a select count(*), keep a derived count somewhere, which is probably going to be faster anyways. Ya, no ideal, but a perfectly valid solution for most.
MySQL is nearly maintanence-free. It just runs and runs.
Perfectly valid comment. However, for the last several releases, there has been an autovacuum daemon available, which takes care of the vast majority of these situations. More below.
PgSQL needs VACUUM and friends.
This is true, however, with the autovacuum daemon, it pretty much takes care of it self. One of the things you'll see in 8.0 is that the daemon is now integrated into the postmaster. This will make it even easier to use and setup.
Once we tried to move a database (from MSSQL) with market data to PgSQL (I think it was 7.4). A lot of stuff was inserted, and a lot of selects performed. Running vaccum/vacuum analyze once in 24 hours was not enough!
That's not all that surprising. It's also possible that you needed some additional tuning on your database, to properly reuse all of your pages, when they were vacuumed.
By the end of the day performance of selects was abysmal. Every time we ran VACUUM ANALYZE, it took longer, and longer, and longer.
This is one of those situations where it pays to be proactive. Assuming you had it configured properly, to correctly reuse all of your pages, you may still needed to run vacuum more than once per day. But, that's not nearly as bad as it sounds. Had you running it, say 20 (wild number here) times a day, via cron, chances are, the whole system would of stayed fast and happy. Once you fall behind the curve, then you'll always be playing catchup. Worse, if you're not reusing all of the pages (tuning issue), performance will continue to get worse and worse, proportionaly to the amount that your not reusing, compounded by not vacuuming often enough.
What about the problem with memory management and cache? I see it's being addressed in 8.0. I have to test 8.0, but with 7.4 it was impossible to run PgSQL efficiently as a dedicated server - grab all available memory and cache everything aggressively. It was very frugal about memory even when it was not necessary.
I assume you mean as a non-dedicated server. Also, assuming you're running on Linux, and using a current kernel (2.6.x), you can tuning the "swappiness" of the kernel, which greatly helps both dedicated and non-dedicated installations.
And, of course, the query optimizer. But that's understandably difficult. I have to see if improvements in 8.0 are significant
Well, you are right that the optimizer is a tough nut. This is why so many give up and allow hints and junk. Just the same, the optimizer generally works pretty well. It's really just a matter of
Well, sequences exist outside the transaction, so I can't say that it should effect it in the least.
I'm running 7.4.2 here and I get this: Session 1: test=# insert into car_type values ( 1 ); INSERT 33665 1 test=# BEGIN; INSERT INTO car (car_type_id) values(1); BEGIN INSERT 33666 1
Session 2: test=# begin; insert into car( car_type_id) values ( 1 ); ERROR: current transaction is aborted, commands ignored until end of transaction block ERROR: current transaction is aborted, commands ignored until end of transaction block
Sounds like he's fudding, using a different isolation level, or using an old version of PostgreSQL.
Prehaps he can restate exactly what his problem is and exactly what his test case is. As he presented it, it would simply fail because of a forign key constraint. As you can see, I inserted a row to allow it...but, it sounds like he's confused or only telling part of the story.
Remember, one of the points of using MVCC is to avoid row locking whenever possible. But, I think you'll be hard pressed to come up with a situation where your desired locking facilities are not provided for with PostgreSQL.
To quote the online documentation: "In addition to table-level locks, there are row-level locks. A row-level lock on a specific row is automatically acquired when the row is updated (or deleted or marked for update). The lock is held until the transaction commits or rolls back. Row-level locks do not affect data querying; they block writers to the same row only."
As far as I'm concerned, the only truly missing feature is distributed transactions. Are there any plans to add them any time soon?
Yes. IIRC, in the last release, the protocol has been expanded to allow for this concept. Nested transactions were also required. These are now in place. I'd guess that two phase commits and distributed transactions (sometime after 2pc) will follow sometime after the 8.0 series stablizes.
In other words, it's on their radar but I don't know what priority they are placing on it.
I agree that speed can be a huge issue in the DB world. Just the same, when it comes to scalability, MySQL rarely stacks up well. Generally speaking, unless you only ever run a single query at any given time, then you'll be better served by another RDBMS. On average, MySQL really is a dog in "real world" environments.
Generally speaking, MySQL's performance is right up there is the great urban myths. Sure, it's wicked fast for a single user with a single query. Add multiple users, multiple queries, or worse, non-select only activity against the queried tables, and MySQL performs like a dog compared to most other RDBMS.
IMO, MySQL got it's performance myth because it was compared to PostgreSQL, back in the early and mid 90's, when PostgreSQL really was slow. These days, PostgreSQL is wicked fast and highly scalable. MySQL, on the other hand, is wicked fast for a single user running a single query whereby, the activity is select only. Attempt to make it scale and MySQL generally falls to the last position when comparing to Oracle, MS SQL, Informix, DB2, and PostgreSQL.
So you're right, speed can be a big thing, just make sure you understand where, why and how, you're getting that performance. Chances are, you're not getting anywhere near the performance you think you are with MySQL.
* Note that I have liberal use of "generally" above. This is because there is no single best RDBMS. PostgreSQL is not always the best tool for the job. Neither is Oracle or MSSQL for that matter. Just the same, use the best tool for the job. Chances are, if you're using MySQL, then odds are, it's not the best tool for the job. Period.
PostgreSQL has always been ahead of MySQL in terms of everything but speed.
That blanket statement is simply not true. Most people think that a single user with a single query is a measure of speed. For most applications, it is not. And bluntly, this is exactly where MySQL's performance advantage starts and stops. MySQL simply does not scale nearly as well as just about any other RDBMS you'll find, including PostgreSQL.
Granted, there are still some corner cases where I'm sure MySQL is faster, especially when you're not using ACID compliant tables, but make no bones about it, PostgreSQL is much faster than most people realize and MySQL is much, much slower than is commonly believed.
Ya but, even the developers do not consider cygwin to be of "production" quality. Rather, they consider the cygwin port to be something worth playing and developing with, under the assumption your productoin environment will NOT be a cygwin host.
Slashdot Mirror
Postgresql is still not quite as fast (in my experience) as MySQL, but the comparison is not fair due to MySQL's lack of features.
Well, for single user experiences, MySQL probably is faster. PostgreSQL tends to scale much, much better than MySQL. In other words, if you have a DB where you expect to have lots of active users with a diverse set of concurrent activity (selects, updates, inserts, deletes), PostgreSQL traditionally zooms way ahead of MySQL. It's a question of how you expect to use your database.
Basically, it's a myth that MySQL is faster than PostgreSQL. A myth, I might add, which MySQL themselves help propagate. Simple fact is, MySQL probably is faster in the developer's eyes. Once it's deployed, PostgreSQL is more than likely the faster of the two. Granted, there are some corner cases where MySQL is still faster than PostgreSQL, but those are the exceptions and NOT the rule.
PostgreSQL got significantly faster in the 7.x release series. With the up coming release of 8.x series, it recieved another signifnicant boost in performance.
The 6.x series was known to be slow. That is very much a thing of the past.
It appears he's even gone beyond the scope of the GPL by offering to replace code written by folks who don't like what he's doing.
How is that BEYOND the GPL? He's using GPL code in his own product that he is selling and the code is NOT available. He is NOT going above and beyond the GPL. He's yet to be meet the letter of the law. Besides, once he offers an application for distriubtion, ALL of his code became GPL. This means, 100% of the code that he uses to build his shareware version is absoluetely, 100%, GPL now.
It's just a matter of shaking the tree hard enough to get this theif to do what the law requires.
No, they didn't specify a license. This is the whole problem.
Actually, they did specify a license. They contributed under the banner of the GPL license. If the project, at the time, had been the BSD license, then the code would of been BSD. Period. The courts are very clear on this. This is cut and dry.
We may assume they intended to license the code under the GPL, but in order to do that you need to _specifically state_ that you are licensing under those terms. They probably didn't.
Not only is this wrong, but the GPL even makes it easier. The second that a release was made with that contributed code, the code was reaffirmed as being GPL licensed. Period. There is no gray area here. ALL of the contributed code is GPL. Period. No then, if he has explicit permission from each contributor to relicense their code, or explicit wording whereby, they render their copyright, ONLY THEN is he in the clear. Until he can prove that such information exists, he is 100%, cut and dry, in violation of the GPL. AND his current closed source product IS a GPL product. Period. Cut and dry.
In otherwords, the burden of proof falls squarely on his shoulders. Until he can prove that the code is NOT strictly GPL or that he owns all of the copyrights, he is in violation of the GPL. Period.
Your assumption about the contributed code being under the GPL is not necessarily clear cut, though probably correct.
Actually, it is very clear cut. Because it's so clear cut, requiring people to assign copyright or provide a pertetual license is the STANDARD remedy to prevent this whole situation.
On the other hand, those contributing probably didn't specify the license they were licensing the code back to him under.
It's not like there is a grey area here. ALL of the contributed code was contributed under the GPL license. No one needs to state what license it's being contributed under because everyone already knows and understands that it's GPL. Period.
It's because of this that ALL of his current code is now GPL. He is attempting to create a closed source product out of GPL code. The GPL is very explicit about this.
The GPL sets the terms under which you can do some things that copyright law normally doesn't let you do.... period.
Agreed, however, there actually are suits by proxy. In most cases, it becomes problematic to execute. In this case, since it's for the common good (the populas) rather than a single company or person, it becomes must easier to execute. After all, the contributed code IS licensed for EVERYONE to consume. This idiot is not preventing everyone from getting their share of the code. Courts are setup to handle this class of problem. It's just traditionally problematic. The only question is, will the FSF step in. Traditionally they won't unless one or more of the authors turn over their copyright. And, I can't blame them because they have finite resources and it makes it meach, much easier and faster.
In this case, from what I can gather, he has CLEAR GPL code being compiled and linked with his non-GPL application. Furthermore, he appears to even admit this, simply stating, on request from a specific section of code's author, the offending code will be removed. Basically, he understands that he's using GPL code and doesn't care. I can't wait for him to get the GPL shoved up his tail pipe. This type of theft is exactly what the GPL attempts to prevent.
You're showing that you're clueless. Zero people have to object to this. Read this clearly. I'll say it again. ZERO PEOPLE HAVE TO OBJECT TO THIS!!! The contributed code was contributed while under the GPL license. That means, the code is GPL!!! Period. I'll say it again, some of the code, even AFTER he dual licensed his code, is GPL code. That means, ALL of the code is NOW GPL, regardless of what his obviously illegal intention was. Period. Because he embeded GPL code into an application, which does not fall under the GPL, his application and associated code is now, 100% GPL. Period. He must now release his code. Period. Unless he can PROVE that people assigned copyright for their contributions to him, he is using GPL code. We all know what that means. In plain English, that means he's trying to be a scumbag theif, knowing full well, that he's stealing GPL code.
There was ONLY two ways to interpret what he's done. One, he's a crook, stealing other people's GPL code. Two, He's a crook, stealing other people's GPL code.
All of the code which he wrote for the windows "shareware" version of X-Chat is now 100% GPL. Period. He is in violation of the GPL license AND in violation of ALL of the contributor's copyrights. Period. At this point in time, his only option is to provide the code which is GPL. That means, ALL of the GPL code. That means, ALL of the code. Period.
If he wanted to avoid all of this, he should of made people sign away their copyright before he would officially add in their submitted code. Or, it should of made it clear that he desired a perpetual license to their contributed works, whereby, he's free to relicense at will. Since he didn't do this, he is illegally embedding GPL code into his non-GPL's licensed product. That means, the instant that he made a distribution of his application available for public consumption, all of the associated works became GPL. Period. End of discussion. He KNEW full well, what he was doing and decided that he had the right to steal. The GPL is specifically set up to catch scum-bags like this.
He's an idiot.
That's 100% wrong. They did specify a license. The donated code under the presumption that the license was GPL. He has zero right to change THEIR licensing agreement. He's completely screwed up here. He wrote some of his own code which he did not want to release. He released it KNOWING FULL WELL THAT IT'S TIED TO GPL CODE. This means that all of his "secret code stash" is now GPL too. He's an idiot. In the attached letter, he even admits that he knows and UNDERSTANDS that the code was contributed under a GPL license. He would have to be an idiot to not know this. Instead of doing the right thing, he simply steals the code and says he'll take it out if someone objects.
He is ABSOLUTELY in violation of the GPL. Period. End fo discussion. You write an application which you knowingly embed GPL code into, your application and all assocaited code, up to and including what you last released, is not 100% GPL. Period. This is EXACTLY what this idiot did. The GPL is VERY explicit about this type of stealing. It's very cut and dry. He's stealing someone else's copyrighted works OR is in violation of the GPL. There is VERY simple to understand.
In a nutshell, he's an idiot. An idiot, which I might add, is in violation of the GPL.
First, great email to this guy. To bad he's too stupid to understand his own situation.
Well, his problem is, people contributed code under the understanding that it was the GPL license. For him to relicense their code, to which he has no copyright, is in error. Bluntly, he in in violation of everyone that has previously contributed code. He can attempt to dance around that fact, but he has two choices at this point in time. One, immediately remove ALL code contributed by all other authors or immediately release all of his current code under the terms of the GPL. Period. He has no other options. If he decides to remove ALL contriubted code, then and ONLY then can he continue down his desired dual license path. The only other chance he has is to obtain copyright from all contributed authors. Until such time, any code which he has written, which uses the strictly GPL (3rd party) contributed code, is tainted by the GPL. That means, once he made available, for release, code which was ONLY licensed under the GPL, all of his new code is ALSO licensed under the GPL.
Strictly stated, no matter what he thinks, he is absoluetely in violation of the GPL. Once he either rips out all of the contriubted code or obtains additional licensing rights, only then would he be free to create a non-GPL binary and still be compliant with the terms of the GPL. In the meantime, he distributed code which is directly tied to GPL code. In otherwords, ALL of the code, up to the point which he last distributed it, must immediately be made available AND licenesed under the terms of the GPL.
Bluntly, he has no choice but to release his modified code. Period. Once he obtains his ownership and/or relicenses the copyrighted works which were contributed by other authors, only then can he do what he's wanting to do. This is EXACLY why the GPL is in place. It's designed to stop crooks like him.
He's getting ready to get spanked hard if he doesn't quickly remove his head from his tail pipe. Bluntly, I havea hard time imagining a bigger idiot.
Tin foil hat? You need to learn more about business.
The grandparent post has a legitimate question and concern. You dismissed it like a fool. Tin foil hat indeed.
Go back and re-read what I said. That alone, is not a huge improvement. A minor improvement with a huge improvement to our ecology is. Together, it's simply awesome.
Until you consider the environmental impact, then it's suddenly a HUGE improvement, with higher effeciency to boot. Right now, people would kill people to have the solution you're turning your nose up at.
From what I understand, hemp would be a great replacement here. Supposedly, it can be harvested 4x more often than corn for ethanol production AND does not require fertilizer or pesticides, which further makes hemp cheaper to grow and harvest, with fewer environmental sie effects. In other words, it's supposed to be more than 4x cheaper (energy wise) to convert hemp into ethanol than corn.
Of course there's this little political problem...
Ya, the political problem is from the oil and chemical companies. Seems that hemp has little to no active ingrediants that are associated with pot, making it a safe commercial crop. Which, I might add, is contrary to what is commonly taught. Accordingly, the reason hemp was outlawed had nothing to do with pot or drug concerns (though that thinking was illogically encouraged), but rather because of lobbying by oil and chemical companies. Seems oil and chemical companies needed a market for their new found abilities to create plastics, nylon, and other artificial fibers, all of which directly compete with hemp.
Your admittedly technologically cool solution is addressing needs of maybe 5% of users leaving the majority out in the cold.
;) Tom is a purist and frankly, it's annoying form time to time. There are times when, as we both see, purity gets in the way of good business sense. But (you knew it was coming), many features which get added (by developres, do make use of these facilities, so it's not really fair to to call Tom out either. He's a smart guy and often sees the whole picture bigger and better then most. Then there are those times when you just want to smack him up side his head. ;) But that doesn't happen very often.
;)
Well, I'm not sure it's right to call it "mine".
I don't exppect to run maintanence jobs (VACUUM) every hour during peak load times becuase otherwise the database does not perform.
In fairness, you haven't had to for a while now, thanks to the AVD. Also worth mentioning is that 8.0 brings new optimizations which will further reduce disk spikes during WAL flush as well as reduce disk spike and CPU hits from vacuumes. Both of which, seemingly are targeted to make YOU happy.
Re-read your words. What you are describing is exactly the steep learning curve: a simple thing requiring a complex solution. Is it not? What about porting issues? Just think about how much effort is wasted by reimplementing every simple query with triggers.
Ya, I thought you might say this. Put it into perspective. Look at the odd contortions that people have to go through with MySQL to do some things, which are trivial on most every other RDBMS. Yet, people still consider MySQL to very simple. And, let's not lose perspective here. It's not like you have to "reimplement every simple query with triggers." That's simply not a fair or honest statement. For smaller tables, use select count(*). For large targets and larger, compute the derived value via a trigger. Which, suddenly makes your select run as fast or faster than most other systems. It's not like select count(*) has to be ruled out completely. But, I clearly see your point and agree somewhere in the middle, somewhat.
Less than MSSQL - no. But that could be just our shop since we have the people with the right experience.
I'd place my money on having the experience. Look at how many versions and how incrementally MSSQL knowledge has been gained. You can't dismiss it and it's certainly not fair to compair years of experience and expertise with zero on a new RDBMS and say one complex and the other is not. Realistically, MSSQL has continued to add many complex and powerful features. It's no longer the trivially easy DB that it was 6 years ago. Likewise, you've learned what and how to do things and what things to avoid. You know how to tune it and it's part of your "trivial" knowledge now. As such, it's not fair to compare the two using such a metric. As I said, each system has their own quirks and caveats, it's just that you have mastered them on MSSQL.
The show stopper was a table with the market data. It had the bars with Open/High/Low/Close. It had about 20 columns, about 5-10 million records for a total 1-1.5GB.
Were all 20 columns commonly queried? If not, paritioning your data may make sense. With tablespaces (versus the old voodoo method), you will be able to more readily spread your disk activity out, which will also greatly help your performance (e.g. index on one disk, WAL on another, table on yet another). Without knowing the details, I'm betting there's a number of optimizations which are available, even with the current stable release (7.4.2, with 7.4.3 or 7.4.4 due out shortly).
The whole table was never kept in RAM, although the RAM was sufficient. The relatively rare queries for historic data trashed the cache, so selects for recent data had to refill it from disk.
Sounds like the need for additional tuning. On a dedicated server, the OS sho
Is using count(*) a bad MySQL habbit?
Absoluetely not. There is nothing wrong with it. It's just the developers don't want to have to hard code an optimal path for that aggregate. The issue exists because PostgreSQL supports user extensible aggregate functions, whereas most DB's don't.
PgSQL is difficult because it has unusual problems, not expected from experience with Oracle/MSSQL/MySQQL
Well, that I'm not willing to swallow. Simple fact is, each and every RDBMS has their own distinct sets of issues, problems, caveats. If something as simple as "select count(*)" is a serious problem, then chances are, you shouldn't be using a database to begin with. While clearly more cumbersome, triggers are easily implemented which allow you to easily and rapidly store derived values, such as counts. This is a very, very minor work around compared what things that MySQL forces people to do. The primary difference is that most people don't realize they they are doing things they hardway with MySQL until they get experience on other systems.
As for aggregates, I know PgSQL functions can't use indexes by design.
I'm not sure we're talking about the same thing here, but PostgreSQL has allowed functional indexes for some time now. But I don't think it would make sense to think that you can create a functional index on an aggregate. I think they were introduced in 7.1 or 7.2. Here's a reference to the 7.2 docs which talk about it.
One quite capable DB admin worked on it full time for about two weeks, another one consulted. They tried everything imaginable. Still, running vacuum slowed selects by 5-10 times. That was not acceptable during the day, thus we could run it only at night. And that was not often enough.
I certainly don't mean to knock your DBAs. My point is, did they attempt to get support from the mailing lists? Did they use the available documentation to it's fullest? Thinking that a Sybase DBA is going make an Oracle database sing, without Oracle DBAs helping, isn't very realistic. That's my point. Far too often, I see people state that they had problems, usually very, very basic problems, but never once bothered to get help from the people that are most qualified to help. Whos failing is that? PostgreSQL's or the DBA's? Obviously, I can't comment on the specifics here, but I think you can understand where I'm coming from.
Yes, you can say they were not experienced enough. I can also say that the configuration was overly difficult.
Well, I certainly do believe that there is a learning curve. You'll find that any non-trivial RDBMS has such a curve. IMO, PostgreSQL is no greater than any other. In fact, I would argue that it's certainly far less steep than Oracle or MSSQL. Having said that, just because there is a curve, is not an excuse (making an assumption here) to not obtain assistance from the wonderful support mechanisms which are readily available to any PostgreSQL user.
I mean a dedicated server, as in nothing but PgSQL 7.4 on a FreeBSD 4.9. Say, the DB is 1GB, server has 2GB RAM. PgSQL should just suck everything in RAM and run read queries directly from there. Why can't it do it? Or maybe it can, but how to configure it in such a way is really non-obvious.
Well, unlike most DB's, PostgreSQL assumes that the OS will do a fair share of caching. This means, you want to leave a fair amount free for system cache. Having said that, for the internal buffers that PostgreSQL does keep, version 8.0 does add several optimizations which greatly enhances many types of workloads (seq scan no longer flushes buffers of commonly used rows, etc).
Many more specifics can easily be gained from reading the documentation, reading the easy to follow tuning guide, which I previously pointed people at, or heck, either doing simple searches of the archives or simply posting a question to a ma
Opps. You're right. I did have an error there and simply ignored it without thought. I'm checking into the situation to see what's going on here.
Thanks.
PgSQL had a very steep lerning curve even for people with experience in other databases. Various unusual stuff just popped up in places which could notbe expected from previous experience elsewhere.
IMO, it has a "very steep" learning curve because so many people have to unlearn all the bad habbits from MySQL. If you're coming to PostgreSQL, and can be bothered to read and follow directions for 30-minutes to an hour, IMO, you'll be on the same footing. In my opinion, the there is a curve, but it's not steep at all, assuming you're not coming from MySQL, where you've been taught to do things counter to just about every other product out there.
How about COUNT(*) and other aggregates?
That's a great question! Sadly, select count(*) is still slow and don't imagine that changing any time soon, at all. Many other aggregates are now faster. These are incremental changes that have been creaping in over the last four of fives releases. Aside from select count(*), PostgreSQL offers a very speedy solution. The general run is, if you really need a select count(*), keep a derived count somewhere, which is probably going to be faster anyways. Ya, no ideal, but a perfectly valid solution for most.
MySQL is nearly maintanence-free. It just runs and runs.
Perfectly valid comment. However, for the last several releases, there has been an autovacuum daemon available, which takes care of the vast majority of these situations. More below.
PgSQL needs VACUUM and friends.
This is true, however, with the autovacuum daemon, it pretty much takes care of it self. One of the things you'll see in 8.0 is that the daemon is now integrated into the postmaster. This will make it even easier to use and setup.
Once we tried to move a database (from MSSQL) with market data to PgSQL (I think it was 7.4). A lot of stuff was inserted, and a lot of selects performed. Running vaccum/vacuum analyze once in 24 hours was not enough!
That's not all that surprising. It's also possible that you needed some additional tuning on your database, to properly reuse all of your pages, when they were vacuumed.
By the end of the day performance of selects was abysmal. Every time we ran VACUUM ANALYZE, it took longer, and longer, and longer.
This is one of those situations where it pays to be proactive. Assuming you had it configured properly, to correctly reuse all of your pages, you may still needed to run vacuum more than once per day. But, that's not nearly as bad as it sounds. Had you running it, say 20 (wild number here) times a day, via cron, chances are, the whole system would of stayed fast and happy. Once you fall behind the curve, then you'll always be playing catchup. Worse, if you're not reusing all of the pages (tuning issue), performance will continue to get worse and worse, proportionaly to the amount that your not reusing, compounded by not vacuuming often enough.
Here is a great PostgreSQL tuning referencea
What about the problem with memory management and cache? I see it's being addressed in 8.0. I have to test 8.0, but with 7.4 it was impossible to run PgSQL efficiently as a dedicated server - grab all available memory and cache everything aggressively. It was very frugal about memory even when it was not necessary.
I assume you mean as a non-dedicated server. Also, assuming you're running on Linux, and using a current kernel (2.6.x), you can tuning the "swappiness" of the kernel, which greatly helps both dedicated and non-dedicated installations.
And, of course, the query optimizer. But that's understandably difficult. I have to see if improvements in 8.0 are significant
Well, you are right that the optimizer is a tough nut. This is why so many give up and allow hints and junk. Just the same, the optimizer generally works pretty well. It's really just a matter of
I can only say, attorney. I am not. Go see one.
Well, sequences exist outside the transaction, so I can't say that it should effect it in the least.
;
;
I'm running 7.4.2 here and I get this:
Session 1:
test=# insert into car_type values ( 1 )
INSERT 33665 1
test=# BEGIN; INSERT INTO car (car_type_id) values(1);
BEGIN
INSERT 33666 1
Session 2:
test=# begin; insert into car( car_type_id) values ( 1 )
ERROR: current transaction is aborted, commands ignored until end of transaction block
ERROR: current transaction is aborted, commands ignored until end of transaction block
Sounds like he's fudding, using a different isolation level, or using an old version of PostgreSQL.
Prehaps he can restate exactly what his problem is and exactly what his test case is. As he presented it, it would simply fail because of a forign key constraint. As you can see, I inserted a row to allow it...but, it sounds like he's confused or only telling part of the story.
Btw, does PostgreSQL have row-level locking yet?
Static docs provide your answers.
Remember, one of the points of using MVCC is to avoid row locking whenever possible. But, I think you'll be hard pressed to come up with a situation where your desired locking facilities are not provided for with PostgreSQL.
To quote the online documentation:
"In addition to table-level locks, there are row-level locks. A row-level lock on a specific row is automatically acquired when the row is updated (or deleted or marked for update). The lock is held until the transaction commits or rolls back. Row-level locks do not affect data querying; they block writers to the same row only."
As far as I'm concerned, the only truly missing feature is distributed transactions. Are there any plans to add them any time soon?
Yes. IIRC, in the last release, the protocol has been expanded to allow for this concept. Nested transactions were also required. These are now in place. I'd guess that two phase commits and distributed transactions (sometime after 2pc) will follow sometime after the 8.0 series stablizes.
In other words, it's on their radar but I don't know what priority they are placing on it.
I agree that speed can be a huge issue in the DB world. Just the same, when it comes to scalability, MySQL rarely stacks up well. Generally speaking, unless you only ever run a single query at any given time, then you'll be better served by another RDBMS. On average, MySQL really is a dog in "real world" environments.
Generally speaking, MySQL's performance is right up there is the great urban myths. Sure, it's wicked fast for a single user with a single query. Add multiple users, multiple queries, or worse, non-select only activity against the queried tables, and MySQL performs like a dog compared to most other RDBMS.
IMO, MySQL got it's performance myth because it was compared to PostgreSQL, back in the early and mid 90's, when PostgreSQL really was slow. These days, PostgreSQL is wicked fast and highly scalable. MySQL, on the other hand, is wicked fast for a single user running a single query whereby, the activity is select only. Attempt to make it scale and MySQL generally falls to the last position when comparing to Oracle, MS SQL, Informix, DB2, and PostgreSQL.
So you're right, speed can be a big thing, just make sure you understand where, why and how, you're getting that performance. Chances are, you're not getting anywhere near the performance you think you are with MySQL.
* Note that I have liberal use of "generally" above. This is because there is no single best RDBMS. PostgreSQL is not always the best tool for the job. Neither is Oracle or MSSQL for that matter. Just the same, use the best tool for the job. Chances are, if you're using MySQL, then odds are, it's not the best tool for the job. Period.
PostgreSQL has always been ahead of MySQL in terms of everything but speed.
That blanket statement is simply not true. Most people think that a single user with a single query is a measure of speed. For most applications, it is not. And bluntly, this is exactly where MySQL's performance advantage starts and stops. MySQL simply does not scale nearly as well as just about any other RDBMS you'll find, including PostgreSQL.
Granted, there are still some corner cases where I'm sure MySQL is faster, especially when you're not using ACID compliant tables, but make no bones about it, PostgreSQL is much faster than most people realize and MySQL is much, much slower than is commonly believed.
Ya but, even the developers do not consider cygwin to be of "production" quality. Rather, they consider the cygwin port to be something worth playing and developing with, under the assumption your productoin environment will NOT be a cygwin host.