Pianeta PostgreSQL

Quando l'elefante si fa uno spuntino...

2012-01-28T10:41:11+00:00

Una immagine veramente significativa che ho trovato per caso e che è attribuita a Command Prompt.

PGDay 2011 @ BSD Magazine

2012-01-21T13:05:48+00:00

Nel numero di Gennaio 2012 della rivista BSD Magazine (dedicata ovviamente al mondo BSD) è stato pubblicato un mio breve resoconto del PGDay 2011. Spero che questo contribuisca a fare crescere ancora di piu' il PGDay Italiano e ITPUG.

PGDay 2011: un evento fantastico!

2011-11-26T18:04:41+00:00

Il PGDay 2011 è stato un indiscusso successo. La conferenza, tornata a Prato (sede di origine dei PGDay) dopo 2 anni di assenza in cui ci si era spostati rispettivamente a Pisa e Roma, si è svolta nel sempre bello e accogliente palazzo della Monash University, che con la sua eleganza e l'ottima organizzazione interna ha fatto sentire ogni partecipante subito a casa. Il numero di partecipanti è

2011-11-09T16:28:32+00:00

È stato finalmente pubblicato e reso noto il programma del PGDay, che prevede due percorsi paralleli, uno di carattere generale e per DBA, l’altro per sviluppatori.

Per maggiori informazioni: http://2011.pgday.it/programma-talks

Ospite d’eccezione sarà Magnus Hagander, membro del Core Team di Postgres e presidente dell’associazione PostgreSQL Europe, che terrà il “Keynote speech” sulle novità di PostgreSQL 9.1.

Altri ospiti della comunità internazionale e del team di sviluppo saranno Simon Riggs, che presenterà due talk (uno sulle differenze fra PostgreSQL ed database NoSQL, l’altro sul futuro di PostgreSQL) e Andreas Scherbaum, che parlerà di Data warehousing con Postgres.

Un’esperienza importante sull’adozione del software open-source che verrà discussa nella track generale è quella di una pubblica amministrazione italiana importante come CSI Piemonte. Altri argomenti interessanti per database administrator saranno disaster recovery, alta disponibilità (HA), Serializable Snapshot Isolation Level (introdotto in 9.1) e infine l’utilizzo di PostgreSQL nel cloud di Amazon EC2.

La track per sviluppatori si presenta interventi sia su importanti novità introdotte in Postgres 9.1 (come tabelle esterne, estensioni, CTE scrivibili), che su argomenti di Business Intelligence (ETL con Kettle), sicurezza e protezione delle password, memorizzazione di contenuti binari nel database. Non mancherà un approfondimento sull’utilizzo di Perl e Node.js per l’interrogazione dei database.

Infine, è stata riservata una sessione speciale per i “lightning talk”, che danno la possibilità a tutti i partecipanti di diventare protagonisti per 5 minuti (tassativi), salendo sul palco e condividendo le proprie esperienze e i propri progetti con Postgres.

A margine della manifestazione (con data e orario da decidersi), si terrà l’assemblea dei soci di ITPUG e l’elezione del consiglio direttivo.

Si invitano i soci che intendono partecipare a giungere a Prato nella giornata di Giovedì e a trattenersi fino al sabato mattina, per partecipare agli eventi sociali che verranno organizzati.

Filed under: Informatica, open source, PostgreSQL Tagged: database, ITPUG, Magnus Hagander, pgday, pgday 2011, postgres, PostgreSQL, PostgreSQL Day, Simon Riggs

PGday 2011: programma on-line

2011-11-08T14:30:02+00:00

E' finalmente disponibile il programma del PGDay 2011!Anche quest'anno ci saranno ospiti della comunità internazionale (Magnus Hagander, Simon Riggs, Andreas Scherbaum) e della comunità nazionale, oltre ovviamente a tutto lo staff di ITPug.

PGDay 2011: pubblicato il programma

2011-11-08T10:25:48+00:00

È stato finalmente pubblicato e reso noto il programma del PGDay, che prevede due percorsi paralleli, uno di carattere generale e per DBA, l'altro per sviluppatori.

Per maggiori informazioni:

PGDay 2011: pubblicato il programma

2011-11-08T08:48:34+00:00

Reso noto il programma del PostgreSQL Day Italiano 2011, la conferenza nazionale sul database open-source PostgreSQL, giunta alla quinta edizione, che si svolgerà a Prato il 25 novembre prossimo. Previste due track parallele e la partecipazione di importanti membri della comunità internazionale.

È stato finalmente pubblicato e reso noto il programma del PGDay, che prevede due percorsi paralleli, uno di carattere generale e per DBA, l'altro per sviluppatori.

Ospite d'eccezione sarà Magnus Hagander, membro del Core Team di Postgres e presidente dell'associazione PostgreSQL Europe, che terrà il "Keynote speech" sulle novità di PostgreSQL 9.1.

Altri ospiti della comunità internazionale e del team di sviluppo saranno Simon Riggs, che presenterà due talk (uno sulle differenze fra PostgreSQL ed database NoSQL, l'altro sul futuro di PostgreSQL) e Andreas Scherbaum, che parlerà di Data warehousing con Postgres.

Un'esperienza importante sull'adozione del software open-source che verrà discussa nella track generale è quella di una pubblica amministrazione italiana importante come CSI Piemonte. Altri argomenti interessanti per database administrator saranno disaster recovery, alta disponibilità (HA), Serializable Snapshot Isolation Level (introdotto in 9.1) e infine l'utilizzo di PostgreSQL nel cloud di Amazon EC2.

La track per sviluppatori presenta interventi sia su importanti novità introdotte in Postgres 9.1 (come tabelle esterne, estensioni, CTE scrivibili), che su argomenti di Business Intelligence (ETL con Kettle), sicurezza e protezione delle password, memorizzazione di contenuti binari nel database. Non mancherà un approfondimento sull'utilizzo di Perl e Node.js per l'interrogazione dei database.

Infine, è stata riservata una sessione speciale per i "lightning talk", che danno la possibilità a tutti i partecipanti di diventare protagonisti per 5 minuti (tassativi), salendo sul palco e condividendo le proprie esperienze e i propri progetti con Postgres.

Il PGDay 2011 si propone di promuovere e divulgare l'utilizzo di PostgreSQL come strumento libero e completo per la gestione di basi di dati, una valida alternativa a soluzioni proprietarie per la rimozione del vendor lock-in e capace di ridurre il costo di proprietà totale (TCO).

Per partecipare all'evento è necessario registrarsi online direttamente dal sito.

PgTAP, l'importanza dei test in PostgreSQL

2011-10-28T14:27:23+00:00

TAP (Test Anything Protocol) è una semplice interfaccia per i test basata su file di testo. TAP nasce col Perl, ma ad oggi ha implementazioni per i più famosi linguaggi di programmazione. PgTAP è l'implementazione di TAP in PostgreSQL.

Non mi dilungherò a descrivere il motivo per cui i test sono importanti, specialmente nell'ottica dello sviluppo agile, che 2ndQuadrant adotta con successo.

PgTAP, sfruttando una sintassi estremamente semplice, permette di testare a fondo il proprio database.

Presupponendo che PgTAP sia stato installato correttamente in un database chiamato pgtap_db, procediamo con la creazione di alcuni oggetti sui quali eseguiremo dei test.

Per informazioni circa l'installazione di PgTAP in un determinato database, rimando alla documentazione ufficiale.

$ psql -c "CREATE TABLE foo AS SELECT generate_series(1,5) AS x" pgtap_db
SELECT 1
$ psql -c "CREATE SCHEMA nuovo_schema" pgtap_db
CREATE SCHEMA
$ psql -c "CREATE FUNCTION say_hello() RETURNS TEXT LANGUAGE SQL AS $$SELECT 'Hello World'::TEXT$$;" pgtap_db
CREATE FUNCTION

Tipi di utilizzo

PgTAP può essere utilizzato per testare qualsiasi aspetto del database. In particolare:

Presenza di oggetti nel database
Controllo dell'esecuzione di query
Controllo dei risultati di una query
Altro

Descriverò in ordine questi aspetti e poi vedremo un esempio pratico.

Presenza di oggetti nel database

Si può controllare l'esistenza di qualsiasi tipo di oggetto nel database. Questo tipo di funzioni ha più o meno la stessa firma, in particolare:

*tipo_di_oggetto*_are( [schema,]  [,description] )

Dove:

tipo_di_oggetto è la categoria di oggetti di cui vogliamo testare la presenza, ad esempio tabelle (tables), funzioni (functions), schemi (schemas) ecc.
schema definisce lo schema in cui gli oggetti devono trovarsi, questo parametro ha senso solo se non si sta testando la presenza dello schema stesso.
array_di_nomi è un array contenente i nomi degli oggetti che devono essere presenti perchè il test abbia successo

Importante: Per avere successo, tutti gli elementi specificati nell'array devono essere presenti. In caso di assenza di almeno uno degli elementi, il test fallirà.

description è una descrizione del test

Nota: Ovviamente, nel caso di schemas_are, il primo parametro, schema, viene omesso.

Controllo dell'esecuzione di query

È possibile testare in modo semplice che una query venga eseguita senza o con errori. Per farlo sono disponibili le funzioni:

throws_ok( query [, errcode] [, errmsg] [, description] )
lives_ok( query [, description] )
performs_ok( query, milliseconds [, description])

Queste tre funzioni controllano rispettivamente:

Che la query generi un'eccezione. È possibile specificare l'errore voluto tramite il parametro errcode
Che la query non generi un'eccezione
Che la query termini entro milliseconds millisecondi

Controllo dei risultati di una query

Spesso si ha bisgno di controllare che una query restituisca esattamente un certo insieme di risultati. PgTAP ha diverse funzioni per questo scopo, la principale è:

results_eq( sql, array [, description] )

Molto intuitivamente, questo test passerà se l'insieme di risultati della query sarà esattamente uguale ai valori presenti in array. Nell'esempio completo presente più in basso, vedremo come sfruttare questa funzione.

Altro

Vi sono poi altri tipi di test, ma citiamo qui solo i più importanti. Per una lista completa invitiamo a consultare la documentazione ufficiale.

Per controllare qualsiasi elemento usando un'espressione regolare:

matches( anyelement, regex [, description] )

Per controllare che un utente sia un superutente:

is_superuser( user [, description] )

Per controllare che una funzione sia scritta in un determinato linguaggio:

function_lang_is( [schema,] function [, args[]] , language [, description])

Per stampare messaggi di diagnostica che non interferiscano con i test:

diag( text )

Nel prossimo articolo vedremo un esempio pratico, dove eseguiremo dei test su un set di oggetti creati per l'occasione.

A presto!

PgTAP, l'importanza dei test in PostgreSQL - Parte 2

2011-10-28T14:15:16+00:00

In questo articolo vedremo un esempio completo di test eseguiti su un semplice set di dati.

Ci sono diversi modi di eseguire i test con PgTAP. È possibile usare pg_prove, uno script installabile attraverso il CPAN, oppure si può scrivere una funzione plpgsql che esegua i test.

In questo esempio, useremo una funzione.

Creiamo un file che contenga i test, chiamamolo risultati_test.sql.

Scriviamo la funzione che lancia i test direttamente nel file, con il nostro editr preferito.

CREATE OR REPLACE FUNCTION risultati_test()
    RETURNS SETOF TEXT
AS $$
BEGIN

    -- Controlliamo la presenza degli oggetti:
    -- Tabella foo
    RETURN NEXT tables_are(
        'public',
        ARRAY[ 'foo' ]
    );

    -- Schema nuovo_schema
    RETURN NEXT schemas_are(
        ARRAY['public','nuovo_schema']
    );

    -- Controlla che sia presente la funzione say_hello
    RETURN NEXT can(
        ARRAY['say_hello']
    );

    -- Controlla che la funzione say_hello sia scritta in SQL
    RETURN NEXT function_lang_is(
        'say_hello',
        'sql'
    );

    -- Controlla che la funzione say_hello non generi errori
    RETURN NEXT lives_ok(
        'SELECT say_hello()'
    );

    -- Controlla che la tabella foo contenga esattamente certi valori
    -- provate a cambiare uno dei valori ed osservare come si comporta il test
    RETURN NEXT results_eq(
        'SELECT * FROM foo',
        'VALUES (1),(2),(3),(4),(5)'
    );

END;
$$ LANGUAGE plpgsql;

Adesso creiamo il file che esegue questa funzione, chiamiamolo test.sql

BEGIN;
\i risultati_test.sql
SELECT PLAN(6); -- Necessario!
SELECT risultati_test();
ROLLBACK;

La prima riga dà inizio ad una transazione. È consigliato inserire i test in una transazione che esegua un rollback prima di terminare, così da essere sicuri che lo stato del databse venga mantenuto intatto.
Successivamente, tramite il comando di psql \i, importiamo il file risultati_test.sql, che crea la funzione che lancia i test.
La riga successiva, SELECT PLAN(6);, serve a specificare il numero di test che intendiamo eseguire (6 in questo caso). È necessaria e controlla che l'esecuzione di un numero di test diverso rispetto a quello specificato, restituisca un fallimento.
La riga SELECT risultati_test(); lancia la funzione che esegue i test.

Abbiamo finito di scrivere i nostri test, possiamo eseguirli con:

psql -f test.sql pgtap_db

Il risultato dovrebbe essere:

BEGIN
CREATE FUNCTION
 plan
------
 1..6
(1 row)

                     testfunction
------------------------------------------------------
 ok 1 - Schema public should have the correct tables
 ok 2 - There should be the correct schemas
 ok 3 - Schema pg_temp_2 or pg_catalog or public can
 ok 4 - Function say_hello() should be written in sql
 ok 5
 ok 6
(6 rows)

ROLLBACK

Si spiega da solo, no? :)

In effetti, lo scopo del protocollo TAP è di essere il più comprensibile possibile. Una serie di ok (in caso di successo) e di not ok (in caso di fallimento) rendono estremamente facile l'interpretazione dei test.

2ndQuadrant Italia utilizza estensivamente PgTAP, il tempo speso a scrivere i test risulta di vitale importanza per la manutenzione dei nostri progetti.

Scansioni "Index-Only" in PostgreSQL 9.2

2011-10-25T10:10:05+00:00

PostgreSQL 9.2 avrà una novità interessante (tra le altre): il supporto per le scansioni di tipo "Index-only". Vedremo in breve cosa sono e perchè sono considerate così importanti dagli addetti ai lavori.

Link al commit di riferimento: http://git.postgresql.org/gitweb/?p=postgresql.git;a=commitdiff;h=a2822fb9337a21f98ac4ce850bb4145acf47ca27

Cosa sono

Le scansioni Index-only sono una novità pensata per migliorare le prestazioni di Postgres. Storicamente ogni miglioramento delle prestazioni viene accolto con entusiasmo dalla comunità (e anche da noi di 2ndQuadrant).

Tramite le scansioni Index-only, una query può essere eseguita sfruttando solo gli Indici, senza andare a interrogare le pagine di memoria su disco dove effettivanente risiede la tabella.

Questo, in determinate circostanze, aumenta notevolmente le prestazioni - dato che vengono risparmiati accessi al disco.

Ma le scansioni "Index" già presenti in Postgres non usano solo gli indici?

Effettivamente no, PostgreSQL esegue le Index scan accedendo sia all'indice che alla tabella sulla quale l'indice è definito.

Questo succede a causa dell'MVCC. Al momento che una tupla viene trovata (tramite ad es. una SELECT) con un Index scan, non è possibile stabilire se quella tupla sia realmente "visibile" a tutte le transazioni attive in quell'istante.

Ad esempio, una trasazione potrebbe aver eseguito un COMMIT che cancellava quella tupla dopo l'inizio della nostra SELECT.

La "visibility map"

L'innovazione che ha portato allo sviluppo delle scansioni "Index-only" si chiama visibility map, ed è presente da PostgreSQL 8.4.

La visibility map è una struttura che contiene un bit per ogni pagina di una tabella. Risulta quindi più piccola della pagina stessa, e risiede facilmente in cache.

Ognuno di questi bit indica se tutte le tuple di quella pagina sono visibili a tutte le transazioni correnti e future.

Sfruttando questa informazione, Postgres è in grado di discriminare se è necessario andare a prelevare dati dalla tabella su disco o meno.

Un esempio pratico

Creiamo, con psql, una tabella con 3000 record composti da un valore intero e da una stringa:

$ CREATE TABLE indexonlytest AS
SELECT
    x AS intvalue,
    'stringa' || x AS stringvalue,
        repeat( md5('2ndQuadrant'),100 ) AS longstring
FROM generate_series(1,3000) x;
SELECT 3000

Creiamo un indice sulla tabella che contenga tutti i campi.

$ CREATE INDEX indextest ON indexonlytest ( intvalue,stringvalue );
CREATE INDEX

Se provo ad eseguire una SELECT sulla tabella, ottengo un Index Only Scan:

$ EXPLAIN ANALYZE SELECT intvalue,stringvalue FROM indexonlytest ORDER BY intvalue LIMIT 20;
                                                QUERY PLAN
 Limit  (cost=0.00..2.01 rows=20 width=36) (actual time=0.039..0.064 rows=20 loops=1)
   ->  Index Only Scan using indextest on indexonlytest  (cost=0.00..301.25 rows=3000 width=36) (actual tim
e=0.039..0.062 rows=20 loops=1)
 Total runtime: 0.078 ms
(3 rows)

Adesso proviamo la stessa cosa senza includere, nell'indice, tutti i campi della tabella.

$ DROP INDEX indextest
DROP INDEX
$ CREATE INDEX indextest ON indexonlytest ( intvalue );
CREATE INDEX

Eseguiamo la stessa SELECT di prima, osservando come si comporta il "planner":

$ EXPLAIN ANALYZE SELECT intvalue,stringvalue FROM indexonlytest ORDER BY intvalue LIMIT 20;
                                                QUERY PLAN
 Limit  (cost=0.00..0.95 rows=20 width=15) (actual time=0.027..0.033 rows=20 loops=1)
   ->  Index Scan using indextest on indexonlytest  (cost=0.00..142.25 rows=3000 width=15) (actual time=0.0
26..0.029 rows=20 loops=1)
 Total runtime: 0.665 ms
(3 rows)

Come si nota, in questo caso il planner ha scelto di utilizzare un normale Index Scan.

Conclusioni

Ovviamente, le informazioni contenute nell'indice devono essere sufficienti a soddisfare le richieste della query. In altre parole, l'indice deve contenere tutti i campi presenti nelle clausole SELECT, WHERE e/o ORDER BY della query.

Ciò non significa che si debba sfruttare sempre questa funzionalità, piuttosto cercare un compromesso: includere tutti i campi di una SELECT in un indice, aumenterà le dimensioni dello stesso, ma permetterà in alcuni casi di utilizzare le scansioni "Index Only".

Ap Camp 2011

2011-10-18T17:11:07+00:00

Ap Camp 2011

View more presentations from Enrico Pirozzi

SpagoBI e PostgreSQL

2011-10-18T17:06:08+00:00

..Dopo due giorni e un quasi esaurimento nervoso sono riuscito a capire l'arcano...

gli script per l'installazione di SpagoBI versione 3.1 su postgresql 9.0.x non sono corretti, per poter far funzionare il tutto
le modifiche da apportare al db sono le seguenti:

alter table sbi_user alter dt_pwd_begin DROP NOT NULL ;
alter table sbi_user alter dt_pwd_end DROP NOT NULL ;
alter table sbi_user alter dt_last_access DROP NOT NULL ;

Dopodi chè lanciare Spago con lo script di startup.sh

Enjoy

Prorogata la Call for paper per il PGDay 2011

2011-10-15T14:33:36+00:00

Il comitato organizzatore del PostgreSQL Day italiano 2011 ha deciso di prorogare di un'altra settimana la Call for Paper. La nuova scadenza è domenica 23 ottobre.

Il PostgreSQL Day 2011 si svolgerà a Prato il giorno 25 novembre prossimo, presso il Monash University Prato Centre, sede delle prime edizioni (2007 e 2008).

Abbiamo già diversi talk interessanti inviati da personaggi di calibro internazionale, che ci parleranno delle novità di PostgreSQL 9.1 e del suo futuro.

Tuttavia, si ricorda che sono ben accetti anche casi d'uso su PostgreSQL. Per cui, se avete una vostra esperienza di eccellenza con PostgreSQL, siete pregati di inviare un abstract seguendo le istruzioni presenti sul sito.

Si segnala infine che è ancora aperta la registrazione early bird che vi permetterà di partecipare al PGDay alla cifra di 41 euro + IVA (necessaria per coprire le spese dei coffee break e del pranzo). Al momento in cui verrà pubblicato il programma della manifestazione, la registrazione salirà a 82 euro + IVA.

Ci stiamo infine adoperando per organizzare attività sociali sia il giovedì sera che il venerdì sera, con l'obiettivo di estendere la partecipazione ai visitatori di questa bella area della Toscana fino a tutto il weekend. Vi terremo aggiornati!

Per maggiori informazioni: www.pgday.it

PgDay 2011: sempre piu' vicino!

2011-10-07T17:19:27+00:00

Manca ormai poco piu' di un mese al nuovo PgDay, il quinto, che torna dopo due anni nella sua sede storica di Prato. Sono disponibili i banner per i blog, quindi se si vuole pubblicizzare l'evento non si ha che da incollare uno dei banner disponibili sul proprio sito.

Importare dati in Greenplum da più file csv con Talend

2011-09-16T08:45:30+00:00

Lavorando con i database, capita spesso di dover importare i dati direttamente da uno o più file CSV. Esistono molteplici strumenti per farlo e spaziano dal copy di psql, via linea di comando, ai più complessi sistemi di ETL come Talend o Kettle. In questo articolo analizzeremo la capacità di Talend di interfacciarsi con un database Greenplum per importare i dati contenuti in 2 file di testo.

Dopo aver scaricato Talend Open Studio (reperibile dal sito di Talend) e dopo averlo installato, possiamo procedere creando un nuovo progetto, e all'interno di questo un nuovo job.

Creiamo quindi le connessioni alle risorse che ci serviranno durante l'importazione, ovvero la connessione al database remoto e i due file csv.

Nella sezione Metadata dell'interfaccia di Talend, aggiungiamo la connessione a Greenplum, dopo aver inserito il nome e i parametri di connessione, il programma creerà un nuovo oggetto di tipo DbConnection.

Cliccando su questo con il tasto destro e selezionando l'opzione "recupera schema", sarà possibile selezionare le tabelle su cui vogliamo lavorare, nel nostro caso la tabella states e la tabella users.

Aggiungiamo ora i file contenenti i dati. Subito sotto l'icona delle connessioni ai database (DB connections), troviamo il gruppo dei file CSV, come precedentemente fatto per i database, clicchiamo con il tasto destro sul gruppo e poi su "crea file delimitato".

Nella prima schermata del wizard che si aprirà, ci verrà richiesto di inserire un nome e una descrizione per la risorsa che stiamo creando. Si passa quindi allo step due, nel quale dobbiamo identificare il file di testo a cui vogliamo riferirci, e la sua codifica. Una volta fatto sarà possibile possibile passare al terzo step, nel quale dobbiamo istruire Talend su come gestire le colonne del CSV. In questa schermata è possibile : selezionare l'encoding del file (1), i separatori di campo e i caratteri di fine linea (2), e qualora fosse necessario, segnalare quante e quali linee devono essere ignorate sia all'inizio che alla fine del file (3). È inoltre possibile segnalare a Talend di utilizzare la prima riga come "schema" del CSV, in maniera che possa prendere i nomi delle colonne direttamente dal file, risparmiando all'utilizzatore l'inserimento manuale del nome delle colonne ( 4 ).

Nel quarto step resta solo da: modificare lo schema del file che stiamo associando, controllare e modificare i tipi di dato riconosciuti in automatico per ogni colonna e, qualora non fossero stati riconosciuti in automatico dalla testata del CSV, modificare i nomi delle colonne e la lunghezza dei campi.

Completato il 4° passo del wizard, il file è correttamente associato all'applicazione e pronto per essere usato.

Una volta aggiunte tutte le risorse che intendiamo utilizzare, è possibile procedere con la creazione del job. Trasciniamo quindi i due file sull'editor visuale del job, e selezioniamo tFileInputDelimited come tipo di file.

Dalla connessione a Greenplum precedentemente creata invece, trasciniamo sull'editor le due tabelle di destinazione (nel nostro caso states e users), e selezioniamo come tipo tGreenplumOutput.

Inseriamo ora un oggetto di tipo tMap - che si trova nella palette degli strumenti alla destra dell'editor visuale - nella cartella "elaborazione" e posizioniamolo fra il file CSV contenente gli stati da importare e la tabella di Greenplum di destinazione. Colleghiamo il file al componente tMap (clic con il destro sul file -> riga -> main) e il componente tMap alla tabella di destinazione (clic destro sulla tabella -> riga -> nuovo output). Una volta collegati fra di loro i componenti possiamo fare doppio click sull'oggetto tMap che permette di associare le righe del file da importare a quelle della tabella di destinazione.

Trascinando i vari campi dalla tabella di sinistra a quella di destra , è possibile associare ogni colonna del file alla colonna relativa sulla tabella di destinazione. Cliccando su ok salveremo l'associazione appena effetuata e i dati sono pronti per essere importati dal file di origine alla tabella di destinazione.

Aggiungiamo ora l'importazione di una lista di utenti dal secondo csv, durante l'importazione è necessario fare lookup sulla tabella degli stati appena riempita, in maniera da verificare l'associazione "utente -> stato", riga per riga. Con il gergo lookup si intende la ricerca di un valore all'interno di un dizionario, utilizzando una chiave al fine di recuperare un ID (solitamente la chiave primaria di quell'oggetto nel database, per garantire integrità referenziale).

Aggiungiamo quindi un oggetto tMap fra il file CSV con gli utenti e la tabella di destinazione, inoltre dalla lista delle tabelle di Greenplum trasciniamo nuovamente la tabella contenente gli stati sulla finestra dell'editor visuale, selezionando come tipo tGreenplumInput.

Colleghiamo quindi i tre elementi al componente tMap, come e' stato fatto precedentemente.

Adesso eseguiamo il mapping fra i tre elementi: questa volta il campo idState del CSV deve essere mappato sul campo idState della tabella states (row3) e quest'ultimo deve essere collegato alla tabella utenti di destinazione. In questa maniera per ogni linea del CSV viene eseguito il lookup sulla tabella stati, assicurando così l'integrità della relazione "Utente - Stato".

Per concludere, facciamo in modo che prima venga eseguita l'importazione dei dati relativi agli stati. Successivamente, quelli degli utenti, in modo da poter eseguire correttamente il lookup. Tracciamo quindi una riga di tipo OnComponentOK (click destro -> attivare -> onComponentOk) dal componente di output della tabella stati a quello di input degli utenti (il file CSV).

In questo modo prima verrano importati gli stati e solo in caso di successo verranno impotati gli utenti.

Adesso basterà cercare il tab di esecuzione nella parte bassa dell'area di lavoro e premere il tasto run per fare in modo che il nostro job venga eseguito.

Il PostgreSQL Global Development Group annuncia il rilascio di PostgreSQL 9.1

2011-09-14T12:01:29+00:00

12 SETTEMBRE 2011: Il PostgreSQL Global Development Group annuncia il rilascio di PostgreSQL 9.1. Quest'ultima versione del leader dei database open source offre tecnologie innovative, estensibilità senza paragoni e nuove funzionalità come replica sincrona, estensioni, tabelle esterne ("foreign data wrapper"), indici "K-Nearest Neighbor".

Rilasciato PostgreSQL 9.1

2011-09-12T13:36:07+00:00

Il PostgreSQL Global Development Group annuncia il rilascio di PostgreSQL 9.1. Quest'ultima versione del leader dei database open source offre tecnologie innovative, estensibilità senza paragoni e nuove funzionalità come replica sincrona, estensioni, tabelle esterne ("foreign data wrapper"), indici "K-Nearest Neighbor".

Nei mesi scorsi, 2ndQuadrant aveva pubblicato una serie di articoli su alcune delle novità di PostgreSQL 9.1, fra cui tabelle unlogged, tabelle esterne ed estensioni.

"PostgreSQL 9.1 fornisce alcune delle più avanzate funzionalità a disposizione di tutti i database open source ed è sostenuto da una comunità attiva e innovativa, con dimostrata esperienza di successo in ambito aziendale. PostgreSQL è inoltre ben posizionato per costruire ed eseguire applicazioni nel cloud", afferma Charles Fan (Vice presidente, Dipartimento di Ricerca e sviluppo, VMware).

Risponde a importanti richieste degli utenti

La versione 9.1 introduce molte funzionalità che per anni sono state richieste dagli utenti, rimuovendo diverse barriere nell'adozione di nuove applicazioni o nella migrazione a PostgreSQL. Fra le altre, sono degne di nota:

replica sincrona: sicurezza e consistenza dei dati (perdita zero) all'interno di un cluster in alta disponibilità di server PostgreSQL;
collation a livello di colonna: definizione delle regole di ordinamento delle stringhe a livello di database, tabella o colonna;
tabelle "unlogged": miglioramenti prestazionali per dati volatili (i.e. caching o sessioni web).

"Heroku offre il più grande servizio cloud per PostgreSQL del mondo come 'database-as-a-service'", svela James Lindenbaum, co-fondatore di Heroku. "Il rilascio della replica sincrona dei dati nella 9.1 fornisce ai nostri clienti modalità innovative per la protezione di dati mission-critical. Consacra inoltre PostgreSQL come una delle soluzioni di memorizzazione dati più dinamiche al momento disponibili".

Avanza lo stato dell'arte

La nostra comunità di sviluppatori è in grado di innovare con funzionalità all'avanguardia. La versione 9.1 ne comprende diverse che rappresentano vere e proprie novità nell'industria dei database anche non open source, come:

indicizzazione "K-Nearest-Neighbor": indici basati sul concetto di distanza, che permettono interrogazioni più veloci nel campo delle ricerche testuali e geografiche;
"Serializable Snapshot Isolation": garanzia di consistenza fra transazioni concorrenti senza necessariamente doverle bloccare, mettendo in pratica il concetto di "true serializability";
"Writeable Common Table Expression": esecuzione di complessi aggiornamenti ai dati su più passi, utilizzando una singola query;
"Security-Enhanced Postgres": implementa la sicurezza di livello militare e il controllo d'accesso vincolato ("Mandatory Access Control").

"OpenERP si è sempre avvalso delle funzionalità di classe enterprise di PostgreSQL per dotare di una base veloce, affidabile e scalabile le applicazioni che aiutano a gestire le operazioni quotidiane delle aziende nostre clienti. L'integrità dei dati in contesti altamente concorrenti e transazionali è un argomento di importanza critica per noi, e siamo veramente entusiasti della funzionalità 'Serializable Snapshot Isolation' introdotta in PostgreSQL 9.1!", aggiunge Olivier Dony, Community Manager di OpenERP.

Estende il motore del database

L'estensibilità di PostgreSQL consente agli utenti di aggiungere nuove funzionalità ad un database già in produzione e di sfruttarlo per compiti che nessun altro sistema di gestione di database è in grado di fare. La versione 9.1 aggiunge nuovi strumenti per l'estensibilità, fra cui:

tabelle esterne tramite "Foreign Data Wrapper": permette di collegare e interrogare altri database direttamente da PostgreSQL;
estensioni: rende più facile creare, caricare e gestire nuove funzionalità del database.

Tutte le funzionalità descritte sopra e molte altre sono descritte in dettaglio sia nella pagina del wiki di PostgreSQL intitolata "What's New In 9.1" che nelle note di rilascio.

Nel 25° anniversario dello sviluppo del database PostgreSQL, la nostra comunità continua a migliorare la tecnologia dei database ad ogni rilascio annuale. Scarica subito la versione 9.1 e prova il più avanzato sistema di database open source al mondo.

Su PostgreSQL: PostgreSQL è il leader dei sistemi di gestione di database open source, con una comunità internazionale costituita da migliaia di utenti e sviluppatori nonché decine di aziende ed enti provenienti da tutte le parti del mondo. Il progetto PostgreSQL vanta 25 anni di attività di ingegneria del software, cominciata all'Università di California a Berkeley e oggi può vantare un ritmo di sviluppo senza uguali. La gamma di funzionalità mature messe a disposizione da PostgreSQL non soltanto è in grado di competere con quelle offerte da sistemi di database proprietari, ma le migliora in termini di funzionalità avanzate, estensibilità, sicurezza e stabilità. Scopri maggiori informazioni su PostgreSQL e partecipa attivamente alla nostra comunità su http://www.postgresql.org e, per l'Italia, http://www.itpug.org.

Per maggiori informazioni in italiano sul rilascio: Press Kit di PostgreSQL 9.1

PGDay 2011 Italiano: Call for paper

2011-09-02T15:46:29+00:00

Lo staff dell'Italian PostgreSQL Users Group (ITPUG) è lieto di annunciare che sono aperte le selezioni per paper, interventi, seminari e tutorial relativi al PostgreSQL Day (PGDay) 2011.

Vedi http://2011.pgday.it/call-papers-cfp per maggiori informazioni.

2011-09-02T10:33:10+00:00

Alla vigilia dell’uscita di PostgreSQL 9.1, lo staff dell’Italian PostgreSQL Users Group (ITPUG) è lieto di annunciare che sono aperte le selezioni per paper, interventi, seminari e tutorial relativi al PostgreSQL Day (PGDay) 2011. L’evento, giunto alla quinta edizione, si terrà a Prato il 25 novembre 2011.

Il PGDay è la giornata nazionale dedicata interamente a PostgreSQL, il più avanzato database Open Source al mondo. Durante l’evento sviluppatori, amministratori, traduttori, appassionati e in generale membri della comunità italiana ed internazionale possono incontrarsi, scambiarsi idee, informazioni e apprendere tutte le ultime novità su PostgreSQL.

All’evento parteciperanno ospiti della comunità internazionale PostgreSQL che terranno talk (in lingua inglese) sullo stato dell’arte del progetto.

Durante il PGDay 2011 vi saranno:

talk regolari (ricerca nel campo dei database, algoritmi e ottimizzazioni, tecniche di amministrazione, disaster recovery, replica, programmazione)

lightining talks (talk brevi, ad esempio per far conoscere il proprio progetto legato a PostgreSQL)

tutorial (mini corsi per facilitare l’apprendimento e l’adozione di estensioni, librerie, e altro legato al mondo PostgreSQL)

sessioni interattive di laboratorio, ove sarà possibile apprendere e mettere in pratica immediatamente le nozioni acquisite, sperimentando le feature di PostgreSQL.

Per tenere un talk al PGDay 2011 occorre inviare il proprio lavoro al comitato di revisione. Il lavoro verrà attentamente revisionato per l’accettazione e gli autori saranno notificati circa l’accettazione/rifiuto del talk.

E’ possibile prenotare un posto per stand, inviando i dettagli circa il prodotto (o i prodotti) che si intendono esibire al comitato di revisione. E’ possibile presentare anche prodotti non OpenSource, avendo però cura di specificare la licenza e il legame con PostgreSQL, nonché i vantaggi derivanti dall’uso di PostgreSQL e gli eventuali contributi forniti alla comunità. E’ inoltre possibile presentare servizi correlati a PostgreSQL, ad esempio consulenza e hosting, presentando in maniera dettagliata al comitato di revisione le modalità di fruizione dei servizi stessi.

Per presentare un tutorial su argomenti avanzati di amministrazione o programmazione di un cluster PostgreSQL è necessario inviare il proprio lavoro al comitato di revisione illustrando dettagliatamente il materiale didattico, le necessità hardware/software e gli eventuali requisiti minimi per la partecipazione al tutorial stesso. Tutti i tutorial devono includere una demo interattiva e possono durare al massimo 60 minuti. Il materiale didattico (ad esempio dispense, code snippets, howto, ecc.) è completamente a carico del relatore (o dei relatori) del tutorial, e deve essere disponibile gratuitamente in forma stampata o elettronica ad ogni partecipante.

E’ possibile fare richiesta immediata per la presentazione di un lightining-talk (massimo 5 minuti) inviando l’argomento e la scaletta del talk al comitato di revisione. E’ tuttavia possibile registrarsi direttamente all’evento per discutere un lightining-talk, previa autorizzazione degli organizzatori e disponibilità di slot di tempo.

Per inviare il proprio lavoro occorre scrivere una e-mail a pgday2011@itpug.org entro e non oltre il 16 Ottobre 2011, avendo cura di specificare le seguenti informazioni:

autore/i del lavoro e relatore designato (è possibile presentare un lavoro congiunto con un massimo di tre relatori);
titolo del lavoro e contesto scientifico/applicativo. Nel caso si tratti di un tutorial specificare in modo esplicito la natura e lo scopo del tutorial stesso;
un abstract di massimo 2000 parole che spieghi in maniera dettagiata e concisa il lavoro stesso;
le eventuali risorse necessarie (connessioni Internet, computer per demo) e la loro disponibilità da parte dell’autore/i;
il tempo stimato per il talk. A tal fine si tenga presente che un singolo talk non puo’ superare la durata massima di 30 minuti e non puo’ durare meno di 5 minuti (lightning talk). Nel caso di tutorial la durata minima deve essere di 30 minuti e la durata massima di 60 minuti.

Le informazioni di cui sopra devono essere inviate in formato testuale o PDF, non saranno accettati altri formati.

La commissione di revisione si riserva il diritto di valutare le informazioni pervenute e di richiederne ulteriori qualora necessario.

Tutti i lavori pervenuti (talk, lightining talks, tutorial) e accettati dovranno essere preparati per la presentazione in accordo alle linee guida che verranno fornite agli autori.

Per maggiori informazioni, visitate il sito 2011.pgday.it oppure seguici su Twitter @PGDayIT2011 .

Il Comitato Organizzatore
Associazione Culturale ITPUG – Italian PostgreSQL Users Group
www.itpug.org

Riferimenti e contatti:
* Sito web: http://2011.pgday.it/
* Twitter: https://twitter.com/#!/PGDayIT2011
* E-mail per informazioni: pgday2011@itpug.org

Filed under: Informatica, open source, PostgreSQL Tagged: call for paper, CFP pgday, open source, pgday, pgday 2011, postgres, PostgreSQL, PostgreSQL Day

Come utilizzare la Virtual Machine di Greenplum Community Edition con VirtualBox

2011-08-27T08:44:40+00:00

Fra i vari download disponibili nella sezione community del sito di Greenplum, è possibile trovare una Virtual Machine con il software già configurato e installato su un sistema CentOs.

La virtual machine è fatta per funzionare con VmWare, ma con qualche piccola attenzione e per puri scopi di valutazione di Greenplum, è possibile farla funzionare anche con VirtualBox.

Dopo aver installato l'ultima versione di VirtualBox (disponibile su http://www.virtualbox.org/wiki/Downloads ) è possibile scaricare l'immagine di VmWare da http://www.greenplum.com/community/downloads/. Una volta ultimato il download, e dopo aver scompattato l'archivio, è possibile procedere con l'installazione.

Innanzitutto creiamo una nuova virtual machine, semplicemente cliccando sul tasto "Nuovo" in alto a sinistra nella finestra di VirtualBox; avremo così accesso al wizard di creazione virtual machine. Dopo la prima schermata introduttiva, nella seconda ci troveremo a scegliere il nome della macchina, che deve essere univoco, e il tipo di sistema operativo. Nel primo dropdown deve essere selezionato "Linux", mentre come versione va scelta Red Hat a 64 bit, essendo la VM basata su CentOs.

Nel terzo step del wizard viene chiesta quanta RAM deve essere allocata alla virtual machine. Di default il programma ne assegna 512 MB, ma per il tipo di ambiente che sta per essere eseguito potrebbero essere pochi. Consiglio quindi di aumentare a 1024 MB la RAM da allocare.

Nella quarta schermata deve essere deselezionato il flag "disco di avvio". Una volta cliccato su continua, VirtualBox ci avvertirà che, continuando senza disco, non potremo fare il boot della macchina. Il disco di boot verrà aggiunto manualmente in seguito: selezionare pertanto "continua". Nell'ultima schermata bisogna semplicemente cliccare su "continua" per completare la creazione della VM.

E' il momento di aggiungere il disco di avvio alla VM appena creata: entrare nelle impostazioni relative alla virtual machine e andare nella sezione "archiviazione". Nell'albero dei controller deve essere selezionata la voce "controller ide" , cliccando sull'immagine del disco con il "+" verde in basso a sinistra, comparirà l'opzione "aggiungi disco fisso. Alla domanda successiva, relativa alla creazione di un disco vuoto, deve essere selezionata la voce "scegli disco esistente". E' possibile ora navigare fino alla posizione dove è stata scompattata l'immagine della virtual machine, e selezionare il primo della serie di files che compongo l'immagine, in questo caso il file si chiama "CentOS 64-bit-cl1.vmdk", riconoscibile come primo della serie per l'assenza di numeri sequenziali nel nome.

Dopo aver aggiunto il disco la virtual machine è pronta per essere avviata. Completata la fase di boot, il sistema proverà a far partire l'ambiente grafico, ma, essendo il sistema configurato per funzionare con VmWare, i driver attualmente installati non possono funzionare con la scheda video virtuale di VirtualBox. Verrà quindi mostrata una schermata blu di errore che chiederà se devono essere visualizzati i log. Dopo aver risposto "No", verrà mostrata un'ulteriore schermata per l'autoconfigurazione di GDM. Anche in questo caso non è quello che serve, quindi la risposta da dare è nuovamente "No".

Si viene quindi condotti a una schermata di login su shell; per accedere l' username è root, la password è password.

Essendo ora amministratori della macchina è possibile lanciare lo script che disinstallerà i driver specifici di VMWare: vmware-uninstall-tools.pl.

lo script eseguirà la disinstallazione completa dei driver. Una volta terminata, è necessario riavviare il sistema. Subito dopo il riavvio ci troveremo nuovamente di fronte alle domande relative al log e all'autoconfigurazione di GDM. Rifiutando come prima, sarà possibile effettuare nuovamente login da shell come root.

E' ora possibile installare i driver di VirtualBox. Per farlo è necessario andare nel menù "dispositivi" di VirtualBox, e selezionare l'opzione "installa guest additions". A questo punto tornando sulla shell è possibile lanciare il comando:

mount /dev/cdrom /media

Andiamo adesso nella directory media:

cd /media

e eseguiamo lo script di installazione dei driver di VirtualBox:

bash VboxLinuxAdditions.run

Purtroppo a causa del kernel troppo vecchio di questa macchina virtuale, non sarà possibile avere l'accelerazione grafica, ma adesso il sistema è pronto per funzionare.

Dopo un ultimo riavvio, il sistema sarà correttamente funzionante anche su VirtualBox, e potrete pertanto avviare i primi passi con Greenplum direttamente da questo sistema.

Ricordiamo che il presente articolo deve essere considerato solamente per scopi di valutazione delle funzionalità di Greenplum Community Edition. Per ottenere performance maggiori, si consiglia di installare Greenplum Community Edition su sistemi non virtuali.

Buon divertimento!

PostgreSQL 9.1 RC 1 è adesso disponibile

2011-08-23T13:42:11+00:00

La prima release candidate di PostgreSQL 9.1 è adesso disponibile. Tutti gli utenti sono pregati di aiutare il progetto scaricando, installando e provando questa versione, in modo da accelerare il rilascio della versione 9.1.

La nuova versione introduce funzionalità come replica sincrona, writeable common table expression, collation a livello di colonna, serializable snapshot isolation e molte altre ancora.

La versione RC 1 contiene correzioni per tutti i principali bug riscontrati nelle varie versioni beta di PostgreSQL 9.1. Al fine di prevenire malfunzionamenti nella prossima release di produzione di PostgreSQL 9.1, è fondamentale che tutti gli utenti testino questa versione e controllino la risoluzione dei bug conosciuti.

Il codice sorgente, insieme a installer binari per diverse piattaforme, sono a disposizione dal sito di PostgreSQL:

PostgreSQL 9.1 Beta 1 è adesso disponibile

2011-08-23T13:41:18+00:00

Un elevato numero di nuove funzionalità come mai si era visto in precedenza è stato introdotto in PostgreSQL 9.1. Alcune di queste sono vere e proprie innovazioni che nessun altro DBMS (commerciale e non) può vantare. Fra le principali e più attese novità di questa versione ci sono:

Replica sincrona
Collation a livello di colonna per database multi-lingua
Unlogged Table
Indicizzazione K-Nearest-Neighbor
Serializable Snapshot Isolation
Common Table Expression (Query WITH) scrivibili
Integrazione con SE-Linux
Estensioni
Tabelle esterne tramite SQL/MED

Il progetto PostgreSQL è nelle mani di tutti gli utilizzatori che sono in grado di provare 9.1beta1, in modo da ottenere un rapido feedback e rilasciare una versione 9.1 stabile che sia libera da bug. Se sei in grado di aiutare nella fase di beta testing, sei pregato di visitare la pagina con le istruzioni sul Beta testing di PostreSQL.

Le versioni beta non sono stabili per natura e non dovrebbero mai essere utilizzate in ambienti di produzione; sono esclusivamente ad uso di test. Ad ogni modo, essendo la lista di funzionalità e le API stabili, gli sviluppatori di applicazioni possono già cominciare a sviluppare applicazioni per PostgreSQL 9.1. Altre versioni beta oppure una versione di tipo "release candidate" saranno disponibili fra alcune settimane.

Il codice sorgente, insieme a installer binari per diverse piattaforme, sono a disposizione dal sito di PostgreSQL:

PostgreSQL l'inaffondabile

2011-08-03T17:33:13+00:00

E' sempre difficile convincere i non utenti PostgreSQL delle capacità di questo fantastico prodotto, penso che la pigrizia e la paura di cambiare siano i motivi che frenano il passaggio a PostgreSQL. Se ogni database facesse bene il proprio mestiere e implementasse correttamente la teoria (transazioni, WAL, rollback, replica,...) e gli standard i prodotti sarebbero realmente interscambiabili, ma

To Dual or not to Dual?

2011-07-07T10:11:46+00:00

Una delle differenze fra PostgreSQL e Oracle e' nel funzionamento sintattico e semantico dell'istruzione SELECT. Agli utenti Oracle potrebbe risultare strano, ma la clausola FROM di una istruzione SELECT in PostgreSQL e' opzionale: Command: SELECT Description: retrieve rows from a table or view Syntax: [ WITH [ RECURSIVE ] with_query [, ...] ] SELECT [ ALL | DISTINCT [ ON ( expression [, ...

Gestire le unita' di misura in PostgreSQL

2011-06-30T20:43:00+00:00

Uno dei problemi di molti, se non tutti, sistemi gestionali e' quello di gestire diverse unita' di misura e le conversioni fra di esse. E' possibile creare nel database una serie di funzioni per la gestione delle unita' di misura e della loro conversione. Prima di tutto occorre fare alcune assunzioni: (1) le unita' di misura sono legate ad un contesto (o dominio), che identifica a quale settore

PostgreSQL 9.1: Tabelle esterne con SQL/MED

2011-06-13T19:28:17+00:00

SQL/MED rappresenta la parte dello standard SQL dedicata alla gestione dei dati esterni (Management of External Data). Anche se SQL/MED è disponibile già a partire da PostgreSQL 8.4, nella versione 9.1 è stata introdotta la possibilità di definire tabelle speciali, dette "foreign", per accedere a dati esterni al database tramite semplici SELECT.

Questo articolo mostra la procedura da seguire per creare una tabella esterna contenente dati ricavati da un file CSV locale e sfrutta un'altra caratteristica introdotta in PostgreSQL 9.1: le estensioni.

Prima di tutto, è necessario installare una estensione chiamata file_fdw distribuita nei moduli contrib di PostgreSQL 9.1.

Per installare i moduli contrib di PostgreSQL 9.1 dai sorgenti è sufficiente compilarli con gmake world e installarli con gmake install-world, oppure entrare nella directory contrib degli stessi sorgenti e digitare gmake install.

Una volta installati i moduli contrib, le estensioni si troveranno in ${postgresql_prefix}/share/extension. Controllate che esistano i file file_fdw.control e file_fdw--1.0.sql, che definiscono l'estensione (si rimanda all'articolo sulle estensioni per maggiori informazioni).

Creare l'estensione con:

CREATE EXTENSION file_fdw;

Il comando psql per mostrare le estensioni è \dx, che possiede anche la variante \dx+, che mostra maggiori dettagli:

test_db=# \dx+ file_fdw
     Objects in extension "file_fdw"
           Object Description            
-----------------------------------------
 foreign-data wrapper file_fdw
 function file_fdw_handler()
 function file_fdw_validator(text[],oid)
(3 rows)

Si noti che questa estensione crea automaticamente un oggetto di tipo FOREIGN DATA WRAPPER di nome file_fdw, che tornerà utile in seguito.

Dato che SQL/MED può gestire la copia dei dati anche attraverso database remoti, è necessario creare un server usando l'oggetto file_fdw (questo passo è necessario anche nel caso si stiano caricando dati da un file locale, come in questo esempio):

CREATE SERVER file FOREIGN DATA WRAPPER file_fdw ;

A questo punto, è possibile creare la tabella esterna caricando i dati, con:

CREATE FOREIGN TABLE statistical_data (field1 numeric, field2 numeric)
   SERVER file
   OPTIONS (filename '/tmp/statistical_data.csv', format 'csv', delimiter ';') ;

Attualmente, è possibile eseguire solo query di sola lettura tramite SELECT sulle tabelle foreign. Le tabelle foreign inoltre, funzionano anche attraverso dblink, il tool che permette la comunicazione tra database remoti.

Concludendo, questa caratteristica va a completare una piccola lacuna che Postgres aveva rispetto ad altri database. Va pertanto accolta con grande interesse data la sua utilità, specialmente nel settore del data warehousing, in particolare dell'estrazione e del caricamento dati (ETL), e in più in generale per l'integrazione del database con altri sistemi e altre fonti di dati.

Per maggiori informazioni si rimanda alla documentazione di PostgreSQL sul comando CREATE FOREIGN TABLE.

PostgreSQL 9.1: le tabelle "Unlogged"

2011-06-06T14:18:19+00:00

Una delle novità introdotte in Postgres 9.1 è rappresentata dalle tabelle "unlogged". Queste tabelle non producono file WAL, cioè quei file che contengono i log delle operazioni di scrittura sulle tabelle.

Eliminando del tutto la scrittura dei file WAL e di conseguenza l'operazione di fsync() al momento del COMMIT della transazione, aumenta considerevolmente la velocità di scrittura su queste particolari tabelle:


postgres=# CREATE TABLE tabella-normale AS SELECT generate_series( 1,1000000 );
SELECT 1000000
Time: 7626.138 ms
postgres=# CREATE UNLOGGED TABLE tabella-unlogged AS SELECT generate_series( 1,1000000 );
SELECT 1000000
Time: 503.786 ms

D'altra parte, l'assenza di file WAL relativi alle operazioni sulla tabella fa sì che il contenuto delle tabelle unlogged non venga mantenuto dopo un riavvio del server causato da un crash (potete divertirvi a provare questo comportamento usando il comando kill sul processo server - preferibilmente non in produzione).

Inoltre, se si usa un sistema di replica come warm standby o hot standby, il contenuto delle tabelle unlogged non viene replicato sui vari slave.

Concludendo, questa nuova funzionalità introduce vantaggi per la memorizzazione di dati facilmente generabili e non durabili. Un caso d'uso comune potrebbe essere il caching, dove la velocità di scrittura è fondamentale e allo stesso tempo non ci si deve preoccupare della persistenza dei dati dopo un crash del server.

Per maggiori informazioni: http://www.postgresql.org/docs/9.1/static/sql-createtable.html.

ll presente articolo è ispirato dal Wiki sulle novità della release 9.1 redatto dalla comunità PostgreSQL.

PostgreSQL 9.1: Le estensioni

2011-06-06T14:17:06+00:00

Una delle caratteristiche più interessanti introdotte in PostgreSQL 9.1 è sicuramente la possibilità di creare delle EXTENSION.

Questa funzionalità risolverà il problema noto a tutti i DBA PostgreSQL che riguardava la gestione delle estensioni (ad esempio PostGIS), in cui ad ogni upgrade di versione le funzioni e i tipi di dato propri dell'estensione si mischiavano con gli altri oggetti del database. Dalla versione 9.1, se opportunamente sviluppate, verranno viste nelle operazioni di dump/restore come un semplice contenitore esterno.

Una EXTENSION è semplicemente un contenitore di oggetti SQL (per esempio tabelle, funzioni, tipi ecc...).

L'idea che molteplici oggetti del database possano essere considerati come un'unica entità porta notevoli vantaggi in termini di gestione e design del database, in quanto con un solo comando si possono aggiungere, modificare o cancellare tutti gli oggetti contenuti in una estensione.

Una caratteristica che ho trovato particolarmente interessante è sicuramente la possibilità di definire dipendenze tra EXTENSION diverse, il che rende ancora più strutturato e facilmente gestibile il design del database.

Ecco un semplice esempio di EXTENSION:

Un'estensione ha bisogno di almeno 2 file, uno chiamato .control e almeno uno chiamato --.sql. Entrambi i file devono risiedere nella directory "extension" presente nella share di Postgres (anche se nel file .control è possibile indicare un path diverso per il/i file .sql).

Un esempio di file hello--1.0.sql:

CREATE OR REPLACE FUNCTION hello_f()
RETURNS TEXT LANGUAGE SQL AS 'SELECT ''Hello World''::TEXT';

E relativo file hello.control:

comment = 'A trivial extension'
default_version = '1.0'
superuser = false

Una volta creati questi due file, è possibile effettuare alcune operazioni, ad esempio:


CREATE EXTENSION hello; 
DROP EXTENSION hello; # Cancella tutti gli oggetti
                      # contenuti nell'estensione
ALTER EXTENSION hello [ADD | DROP] member_object
ALTER EXTENSION hello SET SCHEMA nuovo_schema
ALTER EXTENSION hello UPDATE [TO nuova_versione]

Si rimanda alla documentazione ufficiale di PostgreSQL per maggiori informazioni.

Sono convinto che la facilità di utilizzo e l'estrema utilità renderanno le EXTENSION una delle caratteristiche più apprezzate dagli utilizzatori di PostgreSQL in futuro - oltre che un notevole vantaggio nello sviluppo del software per noi che facciamo consulenze di professione.

EuroPython 2011: PostgreSQL e Python

2011-06-02T17:18:35+00:00

Nel corso di EuroPython 2011, il principale evento annuale per gli sviluppatori e utenti Python in Europa, 2ndQuadrant terrà una sessione speciale di formazione intitolata "The Python and the Elephant". Questo workshop di 4 ore si svolgerà giovedì 23 giugno e coprirà le due principali tecniche di scrittura di applicazioni in Python con PostgreSQL: applicazioni client di tipo standard utilizzando PsycoPG oppure estensioni interne utilizzando il linguaggio PL/Python per le stored procedure.

Il costo per la partecipazione al workshop è di 100 euro a persona. Il numero di posti è limitato e la partecipazione è riservata ai soli possessori di biglietti EuroPython. La registrazione è disponibile dal sito di EuroPython.

"The Python and the Elephant" sarà tenuto da un team di esperti PostgreSQL di 2ndQuadrant composto da Gabriele Bartolini, Peter Geoghegan, Harald Armin Massa e Marco Nenciarini.

2ndQuadrant è uno sponsor di Platino di PostgreSQL e costituisce il più vasto gruppo di "contributor" al progetto PostgreSQL. 2ndQuadrant infatti sviluppa e manutiene sia funzionalità del nucleo di PostgreSQL in materia di alta disponibilità (HA) e performance, che progetti satellite.

2ndQuadrant è uno sponsor di EuroPython 2011, che si svolgerà a Firenze dal 20 al 26 giugno prossimi.

Per maggiori informazioni:

Sito di EuroPython: http://ep2011.europython.eu/
Sito di 2ndQuadrant: http://www.2ndQuadrant.it/

Brain Jumble

2011-05-18T12:13:06+00:00

Da Giovedì 19 a sabato 21 maggio, a Settala (Milano) si terrà l'evento Brain Jumble organizzato dal Comune di Settala e dal Linux User Group di Vignate (VigLug). Giovedì 19 maggio alle ore 15.40 l'Associazione Italian PostgreSQL Users Group terrà un intervento su "PostgreSQL 9, il database open-source più avanzato al mondo", volto a illustrare le potenzialità di PostgreSQL e il suo utilizzo anche in ambienti business critical. Per maggiori informazioni sull'evento Brain Jumble si rimanda al sito http://viglug.org/2011/02/03/brain-jumble-a-settala/

Pianeta PostgreSQL

Quando l'elefante si fa uno spuntino...

PGDay 2011 @ BSD Magazine

PGDay 2011: un evento fantastico!

Share

PGday 2011: programma on-line

PGDay 2011: pubblicato il programma

PGDay 2011: pubblicato il programma

PgTAP, l'importanza dei test in PostgreSQL

Tipi di utilizzo

Presenza di oggetti nel database

Controllo dell'esecuzione di query

Controllo dei risultati di una query

Altro

PgTAP, l'importanza dei test in PostgreSQL - Parte 2

Scansioni "Index-Only" in PostgreSQL 9.2

Cosa sono

Ma le scansioni "Index" già presenti in Postgres non usano solo gli indici?

La "visibility map"

Un esempio pratico

Conclusioni

Ap Camp 2011

SpagoBI e PostgreSQL

Prorogata la Call for paper per il PGDay 2011

PgDay 2011: sempre piu' vicino!

Importare dati in Greenplum da più file csv con Talend

Il PostgreSQL Global Development Group annuncia il rilascio di PostgreSQL 9.1

Rilasciato PostgreSQL 9.1

Risponde a importanti richieste degli utenti

Avanza lo stato dell'arte

Estende il motore del database

PGDay 2011 Italiano: Call for paper

Share

Come utilizzare la Virtual Machine di Greenplum Community Edition con VirtualBox

PostgreSQL 9.1 RC 1 è adesso disponibile

PostgreSQL 9.1 Beta 1 è adesso disponibile

PostgreSQL l'inaffondabile

To Dual or not to Dual?

Gestire le unita' di misura in PostgreSQL

PostgreSQL 9.1: Tabelle esterne con SQL/MED

PostgreSQL 9.1: le tabelle "Unlogged"

PostgreSQL 9.1: Le estensioni

EuroPython 2011: PostgreSQL e Python

Brain Jumble