Software-update: PostgreSQL 8.3.7 / 8.2.13 / 8.1.17 / 8.0.21 / 7.4.25

PostgreSQL is een open source relational database management system dat op diverse besturingssystemen gedraaid kan worden. De ontwikkelaars hebben weer een reeks nieuwe versies uitgebracht met 8.3.7, 8.2.13, 8.1.17, 8.0.21 en 7.4.25 als versienummers. Hiermee worden verschillende fouten opgelost en aangezien één daarvan een denial-of-service zou kunnen veroorzaken, wordt iedereen aangeraden om te updaten. De aankondiging van deze versies ziet er als volgt uit:

PostgreSQL 2009-03-16 Security Update

The PostgreSQL Project today released minor versions updating all active branches of the PostgreSQL object-relational database system, including versions 8.3.7, 8.2.13, 8.1.17, 8.0.21 and 7.4.25. This release fixes a denial of service issue with encoding conversion, and all users should update their installations at the next reasonable opportunity.

There are 12 other minor fixes contained in these update releases, including fixes for xpath() functions in version 8.3. See the release notes for full details.

As with other minor releases, users are not required to dump and reload their database in order to apply this update release; you may simply shut down PostgreSQL and update its binaries. Users skipping more than one update may need to check the release notes for extra, post-update steps.

• Release Notes
• Installation Packages
• Source Code

Note: As previously announced, only versions 8.2.13 and 8.3.7 of the Windows binaries are being released, as we no longer support 8.0 and 8.1 on Windows.

Versienummer	8.3.7 / 8.2.13 / 8.1.17 / 8.0.
Releasestatus	Final
Besturingssystemen	Windows 2000, Linux, BSD, Windows XP, UNIX, Windows Server 2003, Windows Vista
Website	PostgreSQL
Download	http://www.postgresql.org/download/
Licentietype	Voorwaarden (GNU/BSD/etc.)

Reacties (22)

[dsmink]

Ik heb wel eens ergens gelezen dat PostgreSQL beter geschikt zou zijn voor kleinere databases in tegenstelling tot MySQL wat beter zou zijn voor het wat grotere werk.

Ik heb echter geen idee of dit waar is en waar deze informatie vandaan komt of op gebaseerd is. Zijn er mensen die PostgreSQL gebruiken? En voor welke doeleinden? Zijn er grote verschillen tussen MySQL en PostgreSQL bijvoorbeeld?

[Reactie gewijzigd door dsmink op 24 juli 2024 10:08]

[ACM]

PostgreSQL heeft al heel lang een veel completere ondersteuning voor de SQL-specificatie en daarmee wint ie vooral op het gebied van complexe queries en toepassingen al vrij makkelijk zowel op het gebied van performance, onderhoudbaarheid als bruikbaarheid van MySQL.
In MySQL ben ik geregeld tegen bugs of gebrekkige ondersteuning aangelopen voor bepaalde wat complexere zaken in SQL, bijvoorbeeld met betrekking tot subqueries, waar ik in PostgreSQL eigenlijk nog nooit tegen zoiets aangelopen ben. Dan was het hooguit iets dat domweg niet kan in SQL.

Zowel MySQL als PostgreSQL hebben ondersteuning voor grote datasets, waar ze allebei sterkere en zwakkere punten hebben, maar ik zou zelf PostgreSQL verkiezen voor grote datasets, zeker als er complexere queries op losgelaten worden.

MySQL wint vooral juist met de eenvoudigere queries en door een wat lagere connectie-tijd. Maar ondertussen zijn de laatste versies van beide kwa features wel steeds wat dichter bij elkaar gekomen.

[bulle bas]

Ja, MySQL heeft een grote inhaalslag gemaakt wat betreft extra functionaliteit zoals triggers, en ook de mogelijkheid om een strikt-ansimode te gebruiken, zodat correcte syntax kan worden afgedwongen.
MySQL is vooral goed voor bewerking op enkele tabellen. Alle innovaties ten spijt ondersteunt MySQL enkel index nested loop joins. Hash joins [symmetrisch/assymetisch] ontbreken. Sommige queries zullen dus nooit zo efficient kunnen worden uitgevoerd als in postgre, hoe goed je je indexen ook plaatst of probeert aan te sturen met USE INDEX. Het domein waarin MySQL veelvuldig wordt ingezet maakt dat dit probleem evenwel niet al te stringent is: web-databases hebben vaak een eenvoudige structuur, queries omspannen doorgaans een klein aantal relaties en een kleine set rijen.

In Postgres zitten bijzondere wetenschappelijke innovaties, zoals technieken voor adaptive query processing [pdf].

Subqueries worden in mysql niet geoptimaliseerd en zijn daarom tot op de dag van vandaag een enorme ramp. Volgens de ontwikkelaars zitten op dat vlak grote verbeteringen aan te komen in MySQL 6: http://www.scribd.com/doc...-Optimizations-In-MySQL-6

Ik ben alleen bang dat we nog erg lang moeten wachten op versie 6, want versie vijf heeft al zijn nodige vertragingen.

[Reactie gewijzigd door bulle bas op 24 juli 2024 10:08]

[Kettrick]

In a nutshell is MySQL een snelle lightweight database, die ze nu al jaren uitgebreid en stabiel proberen te krijgen.

Postgres is precies omgekeerd, is vanaf de eerste regel gebouwd voor betrouwbaarheid en schaalbaarheid, en ze zijn nu goed bezig om dat sneller en sneller te krijgen.

Ik gebruik overigens al een jaar of vijf Postrgres voor alle projecten die ik doe, ik blijf het een geweldig product vinden

[latka]

Ik weet niet waar je dat gelezen hebt, maar het is eerder andersom: PostgreSQL ligt dichter tegen Oracle-achtige oplossingen aan en is veel strikter in het volgen en implementeren van standaarden.
Ik gebruik PostgreSQL relatief vaak en merk dat ik out-of-the-box veel minder issues heb. Zo hoef ik niet na te denken over welke table-soort ik nodig heb (transactioneel of niet), of ik niet per ongeluk buiten de SQL specificatie bezig ben. Of de optimizer z'n werk wel goed doet...
En als het bloedsnel moet kan in ik PostgreSQL nog altijd een stored procedure schrijven. Iets wat met MySQL pas vrij laat is gekomen.

[Wulfklaue]

Over de inzet op een groot systeem kan ik nog geen mening geven.

Wat ik wel kan zeggen is dat PostgreSQL veel meer geavanceerd is dan Mysql. Mysql is met de laaste versies wel aan het bijbenen qua functionaliteit, maar op die specifieke functionaliteit lopen ze dan weer achter op gebied van speed.

Qua speed op gewoon query's zijn beide +- gelijk, en ik denk dat mysql een voordeel heeft qua speed ( op updates, en inserts ). Wat ook niet verwonderlijk is op de manier dat Mysql's data bewaard ( lees, meer gevaarlijker ). Maar dat is mijn mening.

Daartegen, PostgreSQL kan veel beter scallen met multi cpu's dan Mysql kan. Eenmaal in een multi core omgeving, win PostgreSQL kwa snelheid veel meer, dan Mysql. Waardoor het snelheid voordeel wegvalt.

Je moet wel niet onderschatten, als je van Mysql naar PostgreSQL gaat, dat er enorm wat verschillen durven opduiken. Mysql is meer newbie friendly. Maw, als je het volgende doet in mysql:

SELECT x, y, z FROM a WHERE z = 0 GROUP BY x;

Daartegen moet het zijn in PostgreSQL:

SELECT x, y, z FROM a WHERE z = 0 GROUP BY x, y, z;

Mysql vult automatische bepaalde zaken aan ( wat makkelijker is, maar ook gevaarlijker ). Daartegen bij PostgreSQL ben je verplicht alle velden die je in je SELECT gebruikt ( op de functies na ), ook op te nemen in je GROUP BY.

Ik bekijk het zo: Mysql is de Windows van databanken, en PostgreSQL is de Linux van databanken De laatste is krachtiger, maar een grondige kennis is nodig.

[ACM]

De enige database waar je dat niet bij verplicht bent is vziw MySQL Dus dat moet je niet alleen als punt van PostgreSQL noemen dan.

Het komt er inderdaad gewoon op neer dat PostgreSQL zich meer aan de SQL-specificatie houdt dan MySQL.

[Sfynx]

Qua speed op gewoon query's zijn beide +- gelijk, en ik denk dat mysql een voordeel heeft qua speed ( op updates, en inserts ). Wat ook niet verwonderlijk is op de manier dat Mysql's data bewaard ( lees, meer gevaarlijker ). Maar dat is mijn mening.

Ook met MySQL/InnoDB?

[TeeDee]

HarmB: * TeeDee zit eventjes jouw profiel te bekijken, en met een negatief karma heb je imo niet echt een legitieme voedingsbodem voor dit soort reacties. (Misschien haal je hier ook nog wel fout spel- en tikfouten uit.)

Ontopic maar weer:
Ik ben altijd gecharmeerd geweest van PostgreSQL, alleen nog niks concreets meegedaan. Wat betreft de features komen o.a. MySQL en PostgreSQL inmiddels redelijk overeen, alleen is één van de hoofdredenen voor een mogelijke keuze van PostgreSQL de vage dingen (of beter gezegd het niet volgen van de specs.) van MySQL.

* TeeDee gaat eens op zoek naar het lijstje van ACM Even kijken of die nog relevant is.

[HaTe]

PostgreSQL is vele malen beter en veiliger dan MySQL. MySQL doet dingen die niet kunnen gebeuren.
klik
MySQL word helaas nog zo veel gebruikt..

[fraaije]

Sorry maar ik ben na 20 seconden gestopt met het lezen van het artikel.
Wat een ongelooflijk, totaal ononderbouwd, uit de duim gezogen onzin artikel.

Ik reageer even op een aantal punten in het artikel, welke volgens de auteur niet in MySQL kunnen.

1. PostgreSQL heeft ondersteuning voor transactions
http://dev.mysql.com/doc/refman/5.0/en/xa.html

2. PostgreSQL heeft ondersteuning voor row-locking
http://dev.mysql.com/doc/refman/5.0/en/internal-locking.html

3. PostgreSQL heeft ondersteuning voor stored procedures
Zie http://dev.mysql.com/doc/refman/5.1/en/stored-routines.html

4. PostgreSQL heeft ondersteuning voor FOREIGN KEYs
Zie http://dev.mysql.com/doc/...example-foreign-keys.html

Van alle punten klopt gewoon niks. En waar baseer je op dat PostgreSQL veiliger is?
Volgens mij heeft de auteur van dat artikel nog niet echt door dat je bij MySQL voor elke tabel een andere Storage Engine kunt kiezen.

[cariolive23]

Volgens mij heeft de auteur van dat artikel nog niet echt door dat je bij MySQL voor elke tabel een andere Storage Engine kunt kiezen.

En daarmee haal je jouw punten 1, 2 en 4 onderuit, voor transactions, row-locking en fk's heb je innoDB nodig. Er valt dus helemaal niets te kiezen.

Stored procedures zitten sinds 5.0 in MySQL, maar halen het niet bij de mogelijkheden die PostgreSQL biedt op het gebied van stored procedures.

Wat een ongelooflijk, totaal ononderbouwd, uit de duim gezogen onzin artikel.

Fraaie mening, maar vrij weinig argumenten. Een deel van jouw argumenten die je aandraagt, heb je zelf al weer onderuit gehaald door te stellen dat je diverse engines moet/kunt gebruiken. innoDB is de enige engine die redelijk bruikbaar is. Ook Maria en Falcon veranderen daar niets aan, zijn wederom niet ACID.

PostgreSQL is vooral veiliger op het gebied van data-integriteit. Een volle schijf zal bij pgSQL niet tot een corrupte database leiden, bij MySQL kan dat wel het geval zijn. En zo zijn er nog wel meer voorbeelden te bedenken, daar hoef je geen kenner voor te zijn.

[fraaije]

Onderbouw zelf even je reactie dan waarom dat punten 1, 2 en 4 niet zouden kloppen.
InnoDB is een gewone storage engine van Mysql, dus als iets met InnoDB kan, kan het dus met MySQL.

Stored procedures zitten sinds 5.0 in MySQL, maar halen het niet bij de mogelijkheden die PostgreSQL biedt op het gebied van stored procedures.

Nee en die van PostgreSQL halen het niet bij die van SQL Server. Is dat hier relevant welke uitgebreider zijn? Het ging erom of ze erin zaten ja of nee.

Leuk commentaar, maar van iemand die zelf een weblog heeft over PostgreSQL verwacht ik dan toch wel een linkje naar een artikel waarin je jezelf onderbouwd, waarom bv de stored procedures beter zouden zijn.

[cariolive23]

MySQL kent een tiental verschillende engines waar je tabellen mee kunt maken. Wanneer je echter een relationele database wilt maken die ACID-compliant is (niets bijzonders dus), heb je alleen de keuze uit innoDB. Veel keuze is er dus niet.

De stored procedures in pgSQL zijn imho beter omdat er betere documentatie beschikbaar is. Dat maakt het beter bruikbaar. Daarnaast kun je kiezen voor de taal die jou het beste ligt, wanneer je goed met Perl uit de voeten kunt, is het wel zo handig om Perl voor je stored procedures te gebruiken. Of Java, of C of zelfs PHP. Mogelijkheden genoeg. Wat wel jammer is, is dat je geen packages kunt maken zoals in Oracle.

En ja, ik werk al jaren met PostgreSQL. Verder nog een klein beetje met SQL Server en wat MySQL, ik ken de verschillen.

[Sfynx]

Veel artikelen maken de grote fout alleen de MyISAM storage engine te bekijken. Ik gebruik al jaren standaard InnoDB voor mijn tabellen, tenzij er een echt goede reden is om een andere te kiezen...

[Reactie gewijzigd door Sfynx op 24 juli 2024 10:08]

[dev10]

Zoals FULLTEXT indexes bijvoorbeeld.

[bulle bas]

gebruik liever Sphinx of Lucene daarvoor. Als je met MyISAM uit de voeten kan, dan zitten er geen relaties tussen je tabellen (of je bent gevaarlijk bezig:)). MyISAM is dus alleen goed voor logs e.d.
Sowieso is een ISAM-index behoorlijk ouderwets.

[Reactie gewijzigd door bulle bas op 24 juli 2024 10:08]

[Kettrick]

Het artikel is geschreven in 2006 , in die tijd waren een aantal zaken nog niet aanwezig in MySQL. Het is dus geen ongelooflijk, totaal ononderbouwd, uit de duim gezogen onzin artikel, hooguit een wat achterhaald artikel

[Verwijderd]

Onderbouwing?

[cariolive23]

leesvoer

Het is geen complete lijst, er zitten nog meer problemen in MySQL, maar het geeft een aardig beeld. Het feit dat je MySQL zo kunt configureren dat het aardig gaat werken zegt niet zo veel, iedere database user kan jouw configuratie weer runtime naar de bliksem helpen. Deze rechten zijn ook niet in te trekken, helaas.

Dat er meerdere engines zijn, leuk en aardig, maar er is niet één engine die snel en betrouwbaar is. Je hebt eigenlijk alleen de keuze uit innoDB (ACID) en dat is het. Wil je fulltext search of meer snelheid, zul je al moeten uitwijken naar MyISAM die niet ACID is (daar komt de snelheid ook vandaan, MyISAM controleert niks). Of je moet innoDB met b.v. Sphinx gaan gebruiken, dan doe je de fulltext search eigenlijk buiten de database. Heeft ook als voordeel dat je dan ineens een veel betere fulltextsearch kado krijgt.

MySQL:

SELECT 'a' + 'b';

Dit gaat je in andere databases niet lukken, het is dan ook klinkklare onzin.

PostgreSQL is wat betrouwbaarheid, snelheid en functionaliteit beter vergelijkbaar met Oracle. Op vele punten is de syntax hetzelfde of lijkt het op elkaar, wanneer je met de ene database uit de voeten kunt, snap je de andere database ook wel. En of je nu een kleine database maakt of een grote, PostgreSQL kan het wel aan.

Zie ook deze (serie) tests van Tweakers: Databasetest: achtvoudige Opteron

[Reactie gewijzigd door cariolive23 op 24 juli 2024 10:08]

[desmond]

Met je uitleg over de engines sla je de spijker op zijn kop. Wel blijkt MySQL zonder echte ACID support als backend voor vele CMS'en met relatief lage eisen op dit gebied precies te voldoen! Wordt het datamodel complexer waardoor suquery's e.d. onontkoombaar worden en is ACID compliance een must, dan wordt het tijd om uit te kijken naar iets anders.

Re: Schaalbaarheid: heeft iemand ervaring met MySQL/PostgreSQL op multiterabyte-omgevingen?