Rilasciato PostgreSQL 8.3

PostgreSQLDopo 15 mesi di lavoro è stata rilasciata la versione 8.3 del database relazionale open source PostgreSQL.

I miglioramenti coprono numerose aree: sia dal punto di vista delle prestazioni che da quello delle funzionalità.

Tra le modifiche che ne hanno migliorato le prestazioni, una nuova gestione delle tuple frequentemente aggiornate nelle pagine disco e l’auto-tuning dei checkpoint, della strategia di scrittura in background e del write-ahead log. Sono anche migliorate determinate funzioni quali gli ordinamenti in presenza di operatore TOP, le comparazioni LIKE/ILIKE.

Per i database di grandi dimensioni, è stato ottimizzata la protezione della cache L2 ed è stato introdotto un fantastico sistema (di cui Josh Berkus parlò durante il PGDay dello scorso luglio) di table scan sincronizzati (“a cavalluccio“), per cui una richiesta di table scan può agganciarsi ad una correntemente in esecuzione per sfruttarne parte del lavoro.

Dal punto di vista delle funzionalità, il motore di ricerca full-text, precedentemente disponibile con il package tsearch2, è stato integrato nel core e nel linguaggio SQL (mmm… credo che dovrò aggiornare il dizionario di Italiano per l’installazione nella nuova versione…). Sono poi stati introdotti nuovi tipi di dati, tra i quali il tipo XML (implementato secondo le specifiche ANSI SQL:2003) con controlli su dati ben formati e possibilità di query con xPath, il tipo UUID per la generazione e la memorizzazione di identificativi univoci universali, gli ENUM… relativamente inutili ma comodi per facilitare la migrazione da MySQL. Per gli sviluppatori è anche migliorato il supporto ai cursori nel linguaggio PL/pgSQL.

Con questi miglioramenti, PostgreSQL si conferma il più avanzato database relazionale open source. Le sue prestazioni sono ormai state dimostrate superiori a quelle di MySQL (in particolar modo su piattaforme multi-core) e comparabili a quelle del costoso Oracle. Questo lo rende una alternativa di cui tenere conto per abbattere i costi in progetti di medie e grandi dimensioni.

Comments

  1. maroffo says:

    Possiamo finalmente sepellire mysql?

  2. Sulle prestazioni di PosgreSQL su multicore rispetto a quelle di MySQL, c’è da dire che

    * i benchmark sono appunto benchmark, e raramente rispecchiano il comportamento di una base dati in applicazioni reali

    * MySQL aveva un bug serio nel threading che influiva pesantemente su più connessioni concorrenti, per cui c’è una fix che però è posteriore rispetto a quegli uno-due benchmark che citano sempre tutti i fan di PostregSQL

    Per quel che mi riguarda, sono dello stesso parere dei moltissimi che usano MySQL con soddisfazione (tra cui Yahoo!, YouTube, ecc.), e che ne apprezzano la facilità di utilizzo, la flessibilità, e le opzioni di scalabilità date dal sistema di replica, nativo sperimentato e ampiamente supportato.

    Poi come è ovvio, ogni prodotto ha i suoi punti di forza. PostgreSQL ha un query analyzer migliore, tabelle più compatte (rispetto ad InnoDB) e una maggiore aderenza agli standard. Ma non per questo MySQL è un prodotto scadente, anzi.

  3. :-)

    Lo so che la possibilità di una flame war è meno che remota, quindi da subito dico come la penso un po’ più in là dell’evento del rilascio della nuova versione del PG.

    Secondo me i database relazionali siano arrivati al punto di essere “commoditized”: per la maggior parte delle applicazioni tutti e tre (Pg, My, Oracle) andrebbero egregiamente bene. Lo conferma anche il comportamento della Sun, che sta investendo tantissimo in entrambi i DB OS. Le prestazioni si sono appiattite verso l’alto, questo non può essere che un bene.

    Non è da molto che con un database open source si può fare quello che fino a pochi anni fa si faceva solo con Oracle e con enormi costi. MySQL per me è un pezzo di software concreto: se ho libertà di scelta preferisco PG (per eleganza e consistenza nel comportamento, che per altri potrebbero essere del tutto secondari) ma non mi metterei a piangere se potessi usare solo il My per un certo progetto.

    Penso che vivamo tempi interessanti e che non ci sia mai stata tanta libertà e disponibilità di strumenti potenti. Il modello open source funziona alla grande, ed è un bene per tutti. Ben venga la risposta di MySQL :-)

  4. Piro sono completamente d’accordo con te. Io preferisco My rispetto a PG, ma le mie posizioni sono le stesse. I flame e la partigianeria estrema non convengono a nessuno, specie qui dove cerchiamo di scambiare conoscenza (nel mio caso più pratica che teorica). :)

  5. Scusate una domanda da nubbio,
    se per un applicazione in Php dovessi interfacciarmi con PG invece che MySQL, le differenze a livello di codice cambierebbero molto?

  6. Ci sono numerose applicazioni PHP che funzionano indipendentemente su PG o MySQL, quindi immagino che le librerie driver siano compatibili. A livello di SQL, sarà tanto più difficile quante più feature proprietarie di MySQL sono state usate. Limitandosi a SELECT/INSERT/UPDATE/DELETE puoi scrivere query che funzionano su entrambi i backend.

  7. martino says:

    Di quali risorse software bisogna disporre per imparare a programmare Postgresql?

  8. Di una buona conoscenza di SQL e dell’ottimo manuale di PostgreSQL qui.

Policy per i commenti: Apprezzo moltissimo i vostri commenti, critiche incluse. Per evitare spam e troll, e far rimanere il discorso civile, i commenti sono moderati e prontamente approvati poco dopo il loro invio.