With 8.1, autovacuum is integrated into the main backend, it's no longer a external contrib module. This has several benifits. First, it's easier to setup, just uncoment the setting int he postgresql.conf. Also, you can now set vacuum and analyze thresholds as well as vacuum delay settings on a per table basis. This was probably the biggest problem people had with the contrib version. In addition it is more reliable since DB activity data is no longer lost between database restarts. Also, you can now exclude specific tables from being touched by autovacuum.
I don't understand how too big is really relevant. I assume you are thinking that increased features will reduce performance, however that is not the case with PostgreSQL. With each and every release, the performance improves considerably. If all you want to do is setup some simple tables that will work fine, but you will also have the ability to grown and expand with PostgreSQL.
It's tough to say how they compare. You really need to take time and investigate what is right for you. MS SQL Server is windows only, that is enough to turn some people off. There are lots of differences, each is going to outperform the other in certain circumstances.
Moving autovacuum into the backend not only makes it easier to use, it makes it much more effective. It no longer loses activity data (the info it needs to know when to vaccum) on database restart. Also you can now set vacuum and analyze thresholds as well as vacuum delays settings on a per table basis. This was one of the major problems people had with the contrib autovacuum.
The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source.
When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product.
Last I checked MySQL was only available for free if you used it for non-commercial purposes. Whereas PostgreSQL is free for everyone. I really don't understand why people keep pushing MySQL. The argument that it's faster is only true for the simplest of database applications.
A contrib module was added to 7.4 that figures out when you need to vacuum and does it automatically. In 7.5 this will upgraded from a contrib module and become integrated into the server. So hopefully all the FUD about vacuum will cease.
Originally it was hoped that 7.4 would have a native win32 port. In fact much work has been done, but it didn't get done in time for 7.4. Work continues, and it's getting closer. Everyone working on it hopes that it will be included in the next version of PostgreSQL, but no one will promise. Such is life in an Open Source project.
Ok, there is a lot of talk about vacuum what it does / doesn't do and what effect autovacuum has. Here are the details (FYI, I wrote pg_autovacuum).
Recent versions of postgresql don't take your database offline during vacuum. However, the vacuum process is an I/O intense process and can still, even 7.4, slow the server significantly while it's running. Work is has alredy been done in the 7.5 development tree to address the I/O storm created by vacuum.
Typically, you setup cron to run vacuum your entire database nightly. This is fine, except it has two main problems. 1) It wastes time vacuuming large tables that probably don't need it (think audit train table that only gets inserted into). 2) It probably doesn't vacuum tables that are constantly updated often enough, which results in bloated data files, and slower queries.
The new pg_autovacuum daemon addresses both of these concerns by monitoring database activity (using the stats system). When it sees that a table has has been modified enough to warrant a vacuum then it does so, when it sees that a table might benifit from a analyze only, then it does that. And when a large table doesnt' need to be vacuumed, it doesn't vacuum.
I have a Athlon XP with 1Gig of Ram, and how much if free? 0. Why? Because linux is designed to use all its RAM for file caching and buffering. Free ram is a waste of resources. The best indicator you can get on Linux is to use the free command and look at the numbers that filter out buffering and caching.
Anyone know what is new and improved witht this release? Other than being told 500 times that it has better exchange support anyone know what else changed?
I used to use Opera a lot. Primarily due to the fact that I could have it open up with all my web pages at once. Now that I can do this with Mozilla, I no longer use Opera. The only thing I still miss are the mouse gestures.
Agreed. I just setup unison to sychronize all the files between file servers in multiple offices. Works well, very easy to setup, no kernel hacking required.
Postgresql still does not have a native port to Windows, you still have to use Cygwin. One of the top priorities for the 7.4 release is native win32 support. I will be very happy when that is done.
Novell is trying to integrate their changes back into the main source tree. This has been a slow process though as the port requires many substantial changes and Postgres is in Beta right now for the up coming 7.3 release.
The biggest difference in performance between Postgres and MySQL is connection start up time. That is when a new client connects to a database, MySQL is able to begin servicing that client faster than Postgres. This is due mainly to the fact that MySQL uses threads, and Postgres has to start up a new process. However, this is not a good real world example because nearly all web applications can use persistent connections thus eliminating process start up time. A client server application typically keeps the connection open until it's closed, so the initial startup time for postgres is not relevant here either.
I would argue that in real world use, with persistent connections and a database that is used for more than simple one table selects 99 percent of the time, PostgreSQL is significantly faster.
One issue that is not mentioned in the release highlights is the marked improvement that is now available for SMP boxes. In some cases throughput has been increased by more than a factor of 2.
Unfortunately, they are still running on mysql. I think they would benifit from postgres. The speed issues are mostly moot now, and there are a lot more featueres in postgres.
Slashdot Mirror
With 8.1, autovacuum is integrated into the main backend, it's no longer a external contrib module. This has several benifits. First, it's easier to setup, just uncoment the setting int he postgresql.conf. Also, you can now set vacuum and analyze thresholds as well as vacuum delay settings on a per table basis. This was probably the biggest problem people had with the contrib version. In addition it is more reliable since DB activity data is no longer lost between database restarts. Also, you can now exclude specific tables from being touched by autovacuum.
I don't understand how too big is really relevant. I assume you are thinking that increased features will reduce performance, however that is not the case with PostgreSQL. With each and every release, the performance improves considerably. If all you want to do is setup some simple tables that will work fine, but you will also have the ability to grown and expand with PostgreSQL.
It's tough to say how they compare. You really need to take time and investigate what is right for you. MS SQL Server is windows only, that is enough to turn some people off. There are lots of differences, each is going to outperform the other in certain circumstances.
Moving autovacuum into the backend not only makes it easier to use, it makes it much more effective. It no longer loses activity data (the info it needs to know when to vaccum) on database restart. Also you can now set vacuum and analyze thresholds as well as vacuum delays settings on a per table basis. This was one of the major problems people had with the contrib autovacuum.
Amen Brother! I will never understand the attraction of MySQL.
Not true... Please read:e rcial-license.html
http://www.mysql.com/company/legal/licensing/comm
It has nothing to do with distribution. If your app is open source than you can use the GPL version of mysql, if not, then you can't.
I'm well aware that it is dual licensed, however it's not like you can just choose whichever license you want. From their license found on:
e rcial-license.html
http://www.mysql.com/company/legal/licensing/comm
The Commercial License is an agreement with MySQL AB for organizations that do not want to release their application source code. Commercially licensed customers get a commercially supported product with assurances from MySQL. Commercially licensed users are also free from the requirement of making their own application open source.
When your application is not licensed under either the GPL-compatible Free Software License as defined by the Free Software Foundation or approved by OSI, and you intend to or you may distribute MySQL software, you must first obtain a commercial license to the MySQL product.
Last I checked MySQL was only available for free if you used it for non-commercial purposes. Whereas PostgreSQL is free for everyone. I really don't understand why people keep pushing MySQL. The argument that it's faster is only true for the simplest of database applications.
It's easy, Linus is actually a hobbit. He possesses the ring of power, and is not corrupted by it.
Also he is kinda short and a bit of belly and I have heard that he likes both dinner and supper and have furry feet.
A contrib module was added to 7.4 that figures out when you need to vacuum and does it automatically. In 7.5 this will upgraded from a contrib module and become integrated into the server. So hopefully all the FUD about vacuum will cease.
Originally it was hoped that 7.4 would have a native win32 port. In fact much work has been done, but it didn't get done in time for 7.4. Work continues, and it's getting closer. Everyone working on it hopes that it will be included in the next version of PostgreSQL, but no one will promise. Such is life in an Open Source project.
Ok, there is a lot of talk about vacuum what it does / doesn't do and what effect autovacuum has. Here are the details (FYI, I wrote pg_autovacuum).
Recent versions of postgresql don't take your database offline during vacuum. However, the vacuum process is an I/O intense process and can still, even 7.4, slow the server significantly while it's running. Work is has alredy been done in the 7.5 development tree to address the I/O storm created by vacuum.
Typically, you setup cron to run vacuum your entire database nightly. This is fine, except it has two main problems. 1) It wastes time vacuuming large tables that probably don't need it (think audit train table that only gets inserted into). 2) It probably doesn't vacuum tables that are constantly updated often enough, which results in bloated data files, and slower queries.
The new pg_autovacuum daemon addresses both of these concerns by monitoring database activity (using the stats system). When it sees that a table has has been modified enough to warrant a vacuum then it does so, when it sees that a table might benifit from a analyze only, then it does that. And when a large table doesnt' need to be vacuumed, it doesn't vacuum.
I have a Athlon XP with 1Gig of Ram, and how much if free? 0. Why? Because linux is designed to use all its RAM for file caching and buffering. Free ram is a waste of resources. The best indicator you can get on Linux is to use the free command and look at the numbers that filter out buffering and caching.
It would be nice if Abiword and Gnumetric also switched to the OO formats.
Is Kontact cross platform? I don't think so. So that is one advantage, I would love to know more though.
Actually, I would really like to see a windows version of Evolution. It would help in migrating people to Linux / FreeBSD, just as OpenOffice does.
Anyone know what is new and improved witht this release? Other than being told 500 times that it has better exchange support anyone know what else changed?
I used to use Opera a lot. Primarily due to the fact that I could have it open up with all my web pages at once. Now that I can do this with Mozilla, I no longer use Opera. The only thing I still miss are the mouse gestures.
Agreed. I just setup unison to sychronize all the files between file servers in multiple offices. Works well, very easy to setup, no kernel hacking required.
Bad pun.
Postgresql still does not have a native port to Windows, you still have to use Cygwin. One of the top priorities for the 7.4 release is native win32 support. I will be very happy when that is done.
Novell is trying to integrate their changes back into the main source tree. This has been a slow process though as the port requires many substantial changes and Postgres is in Beta right now for the up coming 7.3 release.
The biggest difference in performance between Postgres and MySQL is connection start up time. That is when a new client connects to a database, MySQL is able to begin servicing that client faster than Postgres. This is due mainly to the fact that MySQL uses threads, and Postgres has to start up a new process. However, this is not a good real world example because nearly all web applications can use persistent connections thus eliminating process start up time. A client server application typically keeps the connection open until it's closed, so the initial startup time for postgres is not relevant here either.
I would argue that in real world use, with persistent connections and a database that is used for more than simple one table selects 99 percent of the time, PostgreSQL is significantly faster.
One issue that is not mentioned in the release highlights is the marked improvement that is now available for SMP boxes. In some cases throughput has been increased by more than a factor of 2.
Unfortunately, they are still running on mysql. I think they would benifit from postgres. The speed issues are mostly moot now, and there are a lot more featueres in postgres.