vvizard writes "After almost a full year of development since PostgreSQL v7.1 was released, the PostgreSQL Global Development Group is proud to announce the availability of their latest development milestone ... PostgreSQL v7.2, another step forward for the project."
Congrats to the PostgreSQL Development team!
by
thing12
·
· Score: 3, Insightful
This is a huge step forward in making PostgreSQL ready for deployment in the enterprise. Eliminating the locking vacuum in favor of a separate statistics gathering process is clearly the best part of this release.
The only major hurdle left is replication built into the server.
Re:Congrats to the PostgreSQL Development team!
by
GooberToo
·
· Score: 4, Insightful
Always remember that table statistics are used for approximate best guesses for inputs to the query optimizer. It is not uncommon or unheard of to actually see somes types of queries run slower after table statistics have been updated. I've seen this on Oracle, Sybase and SQL Server. I doubt that this is an issue unique to those RDBMS since the conceptual implementations and basis for algorithms tend to all be more or less the same.
Online Backups/High Availability
by
murphj
·
· Score: 3, Insightful
I didn't notice anything about online backups, point-in-time recovery, or standby databases. Is any of this possible on PostgreSQL yet? How about clustering/parallel server. Seems like these are important features to become an Oracle/SQL Server replacement.
-- SONY. Because caucasians are just too damn tall.
Re:Why use PostgreSQL instead of MySQL?: ACID
by
Anonymous Coward
·
· Score: 2, Insightful
All true. In fact, MySQL is neither relational nor a DBMS by any stretch of the imagination, if you really understand what these terms mean.
People who try to argue otherwise (including the developers of MySQL), need to go back to school to relearn their math and CS fundamentals. There's a bit of discussion of this at http://searchdatabase.techtarget.com/tip/1,289483, sid13_gci788645,00.html?FromTaxonomy=%2Fpr%2F28487 2
Re:I have only one feature request for PostgreSQL.
by
jcoy42
·
· Score: 3, Insightful
I only have one real gripe about PostgreSQL- I hate the upgrade path.
Having to dump the database to disk and re-import is a bad thing IMO. Having to add a switch to keep integrety constraints is a very odd thing for a database (shouldn't the default be to *keep* integrety constraints?)
A separate program to preserve LOBs I can rationalize (it's a lot of generally unneeded overhead since few people use LOBs).
It would really be nice if someone would write some wrapper programs to check for foreign keys and LOBs, then wrap the pg_dumpall & pg_dump commands with the appropriate options into one set of programs.
-- Never trust an atom. They make up everything.
Re:Why use PostgreSQL instead of MySQL?: ACID
by
Pathwalker
·
· Score: 5, Insightful
Direct SQL is icky? Not if you grok functional languages.
I like SQL - I have no problems understanding SQL. I meant that statement in the sense that it feels more clean (to me) to call a stored procedures in the database from the outside, rather than sending the SQL statements to the database over and over.
It also serves as a handly layer of abstraction from your code, in the event that you want to make drastic changes to the structure of the underlying database.
Maybe I've just seen too much code with SQL commands scattered all over the place, doing the same thing in different fashions at different times, and using strange DB specific constructs at random.
I would prefer to keep the DB specific SQL extensions (if they must be used at all) in stored procedures in the database, and present a consistant interface of stored procedures to the external program. That way, you can support different databases, using the special features they each offer, by providing different database initialization files, and not require any changes to the main program.
Re:Windows version?
by
sc00ch
·
· Score: 2, Insightful
Maybe he wants to learn about pgsql and alternatives to mysql? That would be healthy!
I myself with no experience of cygwin found it a pain in the ass to get postgres working on windows. There was no quick and easy howto on the postgres site at the time, im still unsure if a quick step by step guide exists today.
I'm sure this puts a lot of people off from initially trying out postgres. Mysql makes it a lot easier to check out on windows, simply run the installation program and its up and running.
Slashdot Mirror
The only major hurdle left is replication built into the server.
I didn't notice anything about online backups, point-in-time recovery, or standby databases. Is any of this possible on PostgreSQL yet? How about clustering/parallel server. Seems like these are important features to become an Oracle/SQL Server replacement.
SONY. Because caucasians are just too damn tall.
All true. In fact, MySQL is neither relational nor a DBMS by any stretch of the imagination, if you really understand what these terms mean.
, sid13_gci788645,00.html?FromTaxonomy=%2Fpr%2F28487 2
People who try to argue otherwise (including the developers of MySQL), need to go back to school to relearn their math and CS fundamentals. There's a bit of discussion of this at http://searchdatabase.techtarget.com/tip/1,289483
I only have one real gripe about PostgreSQL- I hate the upgrade path.
Having to dump the database to disk and re-import is a bad thing IMO. Having to add a switch to keep integrety constraints is a very odd thing for a database (shouldn't the default be to *keep* integrety constraints?)
A separate program to preserve LOBs I can rationalize (it's a lot of generally unneeded overhead since few people use LOBs).
It would really be nice if someone would write some wrapper programs to check for foreign keys and LOBs, then wrap the pg_dumpall & pg_dump commands with the appropriate options into one set of programs.
Never trust an atom. They make up everything.
Direct SQL is icky? Not if you grok functional languages.
I like SQL - I have no problems understanding SQL. I meant that statement in the sense that it feels more clean (to me) to call a stored procedures in the database from the outside, rather than sending the SQL statements to the database over and over.
It also serves as a handly layer of abstraction from your code, in the event that you want to make drastic changes to the structure of the underlying database.
Maybe I've just seen too much code with SQL commands scattered all over the place, doing the same thing in different fashions at different times, and using strange DB specific constructs at random.
I would prefer to keep the DB specific SQL extensions (if they must be used at all) in stored procedures in the database, and present a consistant interface of stored procedures to the external program. That way, you can support different databases, using the special features they each offer, by providing different database initialization files, and not require any changes to the main program.
Maybe he wants to learn about pgsql and alternatives to mysql? That would be healthy!
I myself with no experience of cygwin found it a pain in the ass to get postgres working on windows. There was no quick and easy howto on the postgres site at the time, im still unsure if a quick step by step guide exists today.
I'm sure this puts a lot of people off from initially trying out postgres. Mysql makes it a lot easier to check out on windows, simply run the installation program and its up and running.