pgloader e gli URL (compresi quelli di MySQL!)

Un interessante articolo sull'ultima versione disponibile di pgloader.
Noto con piacere che lo script permette di collegarsi autonomamente ad un database differente, es. MySQL, e migrarne il contenuto verso un database PostgreSQL. Ancora meglio, pgloader è in grado di riconoscere e interpretare gli URL che gli vengono forniti scaricando file tramite altri protocolli, come HTTP, per poi leggerli e dump-arli verso una istanza PostgreSQL.

PgAdmin III è ancora vivo!

PgAdmin è sempre stato il tool di riferimento per l'amministrazione di un cluster PostgreSQL mediante interfaccia grafica.
Onestamente non ho mai usato molto tale applicativo, se non quando ero alle prime armi e faticavo a districarmi sulla linea comando di psql,
ma questo non significa che il tool non sia valido, anzi è uno dei piu' completi che abbia mai visto.


La versione forse piu' nota di PgAdmin è la 3, e infatti spesso si trova il nome PgAdminIII. L'interfaccia grafica era spartana ma funzionale, le wxWidgets facevano il loro scopo e rendevano l'applicazione portabile, ma l'eleganza ne soffriva abbastanza.
L'anno scorso è stata rilasciata la versione stabile di PgAdmin 4, completamente riscritto in Python e basato su interfaccia web.
Ciò ha rappresentato una discontinuità nel mantenimento della versione 3, basata su altra tecnologia.


Mi ha fatto piacere scoprire che esiste un fork di PgAdminIII mirato a mantenere il codice attivo e funzionante per ancora qualche versione di PostgreSQL. In effetti, mea culpa, ammetto che l'installazione di PgAdmin 4 non mi risulta mai molto semplice, sicuramente per la mia mancanza di conoscenza Python (nemmeno la wheel sembra funzionare sul mio povero computer!).


Lunga vita a PgAdmin (III o IV)!

Riflessioni su pl/java

Bruce Momjian ha pubblicato un breve articolo circa l'adozione di pl/Java.
I linguaggi pl/ sono una serie di bindings per utilizzare un linguaggio di programmazione differente dal "plain" SQL all'interno di una istanza PostgreSQL, ovvero lato server.
Pertanto pl/java altro non è che un binding per poter utilizzare il linguaggio Java direttamente all'interno del server PostgreSQL, ad esempio per la costruzione di trigger o stored procedures. Io stesso ho utilizzato in passato pl/java in produzione, e ho anche tenuto dei mini corsi e dei seminari sul suo utilizzo (si veda ad esempio qui), nonché ho provato a contribuire a minime porzioni di codice.


Pl/Java risulta abbastanza ostico rispetto ad altri linguaggi pl/, e ciò è dovuto alla natura di Java (non certo ai suoi limiti), in particolare alla fase di compilazione che richiede sempre:

• un deploy di una forza compilata del codice;
  
• un pezzo di codice collante SQL che possa "iniettare" le funzionalità Java dentro al server PostgreSQL.
  

Pl/Java si basa per scelta progettuale su Java Native Interface (JNI), scelta abbastanza efficiente se si considera che il codice deployato risulta locale al server cluster e quindi non è necessario utilizzare chiamate remote (es. RMI). In modo coerente con le scelte architetturali di PostgreSQL, pl/java utilizza una virtual machine backend per ogni processo attivo, richiedendo quindi dei tempi di startup piuttosto lunghi (o diciamo piu' lunghi rispetto ad altri pl/).


L'implementazione di pl/java è elegante e interessante, permette la sincronizzazione dei thread su un mutex singolo e consente di interagire con gli oggetti di backend arrivando perfino a implementare una sorta di SQL MED del poveraccio.


Eppure pl/java non sfonda, come nota appunto Bruce nel suo articolo.


Avendolo usato in produzione posso affermare che pl/java è fortemente condizionato dalla competizione con altri linguaggi pl, in particolare quelli di scripting. Effettivamente io stesso, ad un certo punto, ho modificato porzioni di codice abbastanza sostanziose per passare da pl/java a pl/perl. Ovviamente ciò è stato possibile perché potevo scrivere codice in entrambi i linguaggi, competenza non sempre presente, e l'esigenza principale è stata quella di dover garantire una modifica on-the-fly al codice sorgente anche quando non fosse disponibile un ambiente di sviluppo completo. Detto in due parole: per usare pl/java occorre impostare un progetto (Eclipse o similare), compilare, deployare e "iniettare" il codice nel backend, in pl/perl basta un editor di testo per modificare il codice e la fase di deploy si riduce ad iniettare il codice nel backend.


Personalmente ritengo che pl/java sia uno strumento interessante e importante, e che la sua adozione in contesti fortemente Java-based (per competenze, librerie, stack) sia opportuna, ma solo da un punto di vista degli sviluppatori. Difficilmente un DBA utilizzerà pl/java per implementare le proprie logiche di controlle server-side.

Ulteriori considerazioni sul planet PostgreSQL italiano

Qualche mese fa avevo espresso brevemente alcune considerazioni sul futuro dell'aggregatore di blog dell'associazione ITPUG, ovvero il Planet PostgreSQL Italiano.
La mia preoccupazione era dovuta al fatto che nei primi mesi dell'anno corrente non vi erano stati post relativi all'associazione e al mondo PostgreSQL in generale, e infatti facevo notare come solo io avessi pubblicato 13 post fra Gennaio e Aprile.


Ad oggi, giro di boa della metà anno, la situazione non è migliorata, e ancora una volta pare che il planet sia utilizzato solo per aggregare i miei post:

• 14 Aprile
  
• 5 Maggio
  
• 6 Maggio
  
• 8 Maggio
  
• 19 Maggio
  
• 20 Maggio
  
• 11 Giugno
  

Ancora una volta sento la necessità di sollecitare l'associazione e il consiglio a valutare l'utilizzo di questo strumento di aggregazione e informazione, che risulta ormai evidentemente abbandonato a se stesso e in rapido declino di contenuti (a differenza del sempre aggiornato Planet PostgreSQL.

Perl blogs will be powered by PostgreSQL

There is a grant request aiming at revamping blogs.perl.org.
I have to admit that blogs.perl.org is in a bad shape, and in fact I do not use it anymore for my personal contents since the well known
login issues.
Well, the important part about the grant request, at least with regard to the PostgreSQL community, is that…surpise! The new platform will store content on a PostgreSQL backend:

[…]
will be written on top of Dancer2,
DBIx::Class, and DBI,
with a PostgreSQL database
imported from the existing
[…]

A great news for two of my favourite Open Source projects (Perl and PostgreSQL) and a great wat to spread the word thru our own content!

PostgreSQL abbandonerà il supporto al download FTP

Dal giorno 15 Agosto 2017 non sarà piu' possibile scaricare PostgreSQL tramite FTP!
Come spiegato nella mailing list pgsql-announce, visto il basso traffico
del protocollo FTP, nonché la vetustà del protocollo e dei relativi programmi,
il team che mantiene l'infrastruttura ha deciso di spegnere l'accesso FTP.
Questo non dovrebbe risultare in un particolare disservizio per gli utenti finali, quanto
forse solo per alcune applicazioni e script automatici.

PostgreSQL 10 beta 1!

Ci siamo!
PostgreSQL 10 fa finalmente capolino nel mondo con il rilascio, ieri, della prima beta release.
Il download comprende pacchetti binari per le maggiori distribuzioni, oltre ovviamente alla possibilità
di compilare i sorgenti, anch'essi scaricabili come archivi.

API Java per la replicazione PostgreSQL

Con l'avvento della versione 42 del driver JDBC per utilizzo di applicativi Java su database PostgreSQL è stato fornito
il supporto alla replicazione.
E' stata creata una API apposita per la gestione della replicazione, il cui punto di ingresso è getReplicationAPI() sull'oggetto PGConnection, come
descritto nella documentazione:

The entire replication API is grouped
in org.postgresql.replication.PGReplicationConnection
and is available via org.postgresql.PGConnection#getReplicationAPI.

Questa feature permette di controllare e gestire la replicazione anche da applicativi esterni (Java).
Ahimé il corrispondente driver Perl (DBD::Pg) non supporta la gestione della replication, nonostante
l'infrastruttura DBI consenta una gestione generalizzata della replica. Anche il framework
DBIx non mi pare offra una soluzione, seppur esista un "minimale" supporto
alla replica logica a livello di tabella. La cosa strana è che Bucardo è un sistema di replica implementato in Perl!

Toolchain e qualità PostgreSQL

Ho trovato una presentazione interessante sul mantenimento del code base di PostgreSQL, che come è ben noto,
ha una dimensione piuttosto estesa e una qualità del codice elevata.
La presentazione, non particolarmente dettagliata nelle sue slide (e quindi di facile lettura),
percorre ed elenca i principali strumenti e termini usati all'interno del progetto, dalle notizie e le mailing list,
al metodo di invio di una patch e alla relativa revisione e test automatico del codice.
Ritengo sia sempre utile valutare quali strumenti i grossi progetti utilizzano e il workflow, anche di alto livello,
che adottano.

Ancoa sul "caso" PostgreSQL e Uber...

Chi si ricorda il caso di Uber che, dopo attenta valutazione decise di passare a MySQL e abbandonare PostgreSQL?
I commenti sulla vicenda si sono sprecati, e la community PostgreSQL ha da subito mostrato
un approccio costruttivo alla vicenda sezionando e spiegando in dettaglio
come le limitazioni presentate da Uber erano in realtà scelte progettuali e/o
ostacoli superabili con estensioni (si veda per esempio il post di Simon Riggs).


Ora Christophe Pettus ha prodotto una presentazione molto interessante e dettagliata
che riassume quanto affermato da Uber e come questo, seppur vero in teoria, non sia mai stato documentato opportunamente e,
soprattutto, non sia mai stato valutato adeguatamente.
Non voglio difendere PostgreSQL a spada tratta, penso che una compagnia come Uber abbia sicuramente
personale qualificato per prendere la decisione migliore, anche se come spiegato nella presentazione
di cui sopra spesso si è fatta confusione confrontando cose differenti negli stessi ambiti (ad esempio
la replica, comparando la logical replication con la streaming replication).

Dimensioni delle tabelle e dei dati dump di testo, qualche insignificante esperimento

Mi sono ritrovato per le mani una vecchia e obsoleta istanza PostgreSQL 8.4 piuttosto grossa, lo spazio disco del tablespace
risultava essere di circa 13 GB! Ho quindi preso spunto per fare una piccola indagine su cosa occupasse tanto spazio,
concentrandomi solo sulle relazioni (tabelle):

SELECT c.oid,nspname AS table_schema
      , relname AS TABLE_NAME
      , c.reltuples AS row_estimate
      , to_char( pg_total_relation_size(c.oid)::real/(1024*1024), '99G999D99' ) AS MB
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE
      relkind = 'r'
      AND
      nspname = 'public'
ORDER BY 4 DESC, 3 ASC;

Ebbene sono saltate subito all'occhio tre tabelle in particolari (nomi di fantasia):

  oid   | table_schema | table_name | row_estimate |     mb
---------+--------------+------------+--------------+------------
   63740 | public       | tab1      |  8.74153e+06 |   2.248,58
   66161 | public       | tab2      |   2.9728e+06 |   1.192,00
   65032 | public       | tab3      |  2.44735e+06 |   1.280,77

Come si nota queste tre tabelle superano di slancio ciascuna una occupazione di 1 GB, arrivando fino a 9 milioni di tuple circa!
Insomma, non una cosa eccezionale per PostgreSQL, ma sicuramente nemmeno una cosa di routine, e che comunque indica forse la necessità
di una riprogettazione o di un partitioning.
Comunque, le stesse tabelle su disco quando occuperebbero in formato testo?

% pg_dump -h localhost -U luca -t tab1 testdb > tab1.sql

Effettuando il dump, con molta pazienza, di quelle tre tabelle sopra indicate si ottiene che:

% ls -lh tab?.sql
-rw-r--r-- 1 luca luca 579M 2017-04-12 11:32 tab1.sql
-rw-r--r-- 1 luca luca 494M 2017-04-12 11:37 tab2.sql
-rw-r--r-- 1 luca luca 571M 2017-04-12 11:36 tab3.sql

e quindi lo spazio occupato all'interno di PostgreSQL risulta da 2 a 4 volte superiore allo spazio disco dei dati testuali.
Chiaramente questa non rappresenta una inefficienza di PostgreSQL, quanto una naturale esigenza del database di tenere i dati allineati,
avere le pagine dati (8kB) con spazio sufficiente per consentire aggiornamenti, ecc.


Se si effettua un vacuum full sulle tabelle di cui sopra si ottiene il seguente risultato:

> vacuum full verbose tab1;
...
0 index pages have been deleted, 0 are currently reusable.

ad indicare che il database era già "buono", e abbastanza compattato. Ovviamente i dati che PostgreSQL riporta sul numero di tuple e dimensione
dei dati sono rimaste invariate.

Considerazioni sul planet italiano di PostgreSQL

Ho fatto caso che ormai sul planet ufficiale dell'associazione ITPUG, ovvero www.planetpostgresql.it, sto scrivendo
sporadicamente solo io. Questo secondo me è un campanello di allarme: io non sono certo migliore o piu' bravo di altri
soci e componenti dell'associazione, ma questa assenza dell'associazione dal planet indica che forse non si crede piu'
in questo strumento. Il fatto però è che nemmeno sul planet ufficiale si leggono post di ITPUG, e quindi non è tanto
la piattaforma italiana ad essere trascurata, ma il sistema di pubblicazione di notizie e articoli in generale.


Tornando al planet italiano, è facile verificare che su un periodo abbastanza ampio gli unici post
aggregati sono miei, e spesso risultano a loro volta dei link ad altre notizie ed articoli:

1. 6 Gennaio 2017
2. 13 Gennaio 2017
3. 18 Gennaio 2017
4. 27 Gennaio 2017
5. 3 Febbraio 2017
6. 21 Febbraio 2017
7. 23 Febbraio 2017
8. 24 Marzo 2017 (a) e (b)
9. 2 Aprile 2017
10. 5 Aprile 2017 (a) e (b)
11. 8 Aprile 2017

Possibile che in un periodo di circa 3 mesi ITPUG non abbia avuto nessuna notizia da pubblicare?
Perfino in questi giorni, dove si richiede la regolarizzazione della quota per l'anno 2017 in vista
dell'imminente assemblea ordinaria, non vi sono notizie a riguardo.


Il consiglio che mi sento di dare al futuro consiglio è quello di prendere una decisione in merito al planet: se non lo si
vuole aggiornare allora tanto vale "spegnerlo", ma se lo si mantiene (come è tradizione anche nell'ambiente PostgreSQL e non solo)
allora lo si deve popolare periodicamente.

PostgreSQL ltree

Da un thread su una delle mailing list ufficiali ho appreso di un tipo di dato a me sconosciuto: ltree.

Un ltree rappresenta un label tree, quello che nei linguaggi di programmazione è un meccanismo di properties. In sostanza

si definiscono delle etichette, ordinate gerarchicamente in base ad un separatore (il carattere .) e a queste si associa un valore.

Esistono poi funzioni apposite di utilità per la navigazione e la ricerca nell'albero delle etichette.

Vediamo un esempio pratico: supponiamo di voler catalogare in un albero alcune informazioni basilari riguardo la nostra associazioni

(dati assolutamente casuali e a puro scopo didattico!).

CREATE TABLE 

itpug( tipologia ltree, counter integer );

Ora si supponga di voler trovare il dettaglio dei soci, magari la loro somma partendo dalla foglia dell'albero:

SELECT sum( counter )  

FROM itpug  

WHERE tipologia @> 'itpug.soci';
 sum
----
  50
(1 row)

Supponiamo di voler trovare tutte le informazioni relativi al web (si noti l'uso della tilde):

SELECT *  

FROM itpug  

WHERE tipologia ~ '*.web.*';
         tipologia         | counter
---------------------------+---------
 itpug.web.siti            |       3
 itpug.web.ssl.certificati |       1
(2 rows)

Insomma, ltree si presenta come estensione sicuramente interessante, anche se forse un po' sorpassata dall'uso di altri formati quali json e jsonb.

Planet PostGIS

Scopeto da poco e quasi per caso: il planet.postgis.net è il planet ufficiale dell'estensione spaziale di PostgreSQL. La sua funzione è simile a quella del planet ufficiale di PostgreSQL: aggregare notizie ed esperienze da blogger di tutto il mondo relativamente al solo ambito GIS.

Non è sicuramente uno dei planet che leggerò quotidianamente, ma vale la pena tenerlo presente per avere un'idea dell'evoluzione del mondo GIS legato all'ecosistema PostgreSQL.

if-else in psql

Un articolo interessante che punta ad un commit di Tom Lane (e altri) per l'introduzione in psql di un costrutto if-else, ovvero \if, \elif, \else.

Mi torna subito alla mente Larry Wall in Programming Perl: soltanto un Algol-er potrebbe usare una parola chiave che è file scritto al contrario.

Ad ogni modo la modifica, che verrà introdotta con PostgreSQL 10, permette l'uso di costrutti condizionali basilari in psql. Si presti attenzione

che questi non sostituiscono i costrutti condizionali di plpgsql, ma si inseriscono direttamente nell'interprete SQL base fornito a corredo di

praticamente ogni installazione.

Sarà quindi possibile realizzare script automatici piu' complessi da dare in pasto al nostro fidato amico psql.

Pipeline di una query in PostgreSQL

Una interessante spiegazione da parte di Tom Lane sulla pipeline di una query.
Anche se si fa riferimento all'utilizzo, non ammesso dallo standard SQL, degli alias SELECT in una clausola WHERE, la mail spiega in modo molto dettagliato come devono essere valutati
i vari passi della sintassi di una query.

Caratteri, codifiche, ordinamento

Un articolo molto chiaro e sintetico che aiuta a tenere a mente i concetti dietro collation, charater encoding e charset.

Consiglio vivamente la lettura.

SpeakerFight & PGDay.IT: è possibile?

Sono venuto a conoscenza per caso di un progetto interessante: SpeakerFight.
L'idea è abbastanza semplice, e l'implementazione mantiene la semplicità: si inviano dei contributi di talk (per conferenze ed eventi) e si lascia che le persone li votino, in un meccanismo stile "star" ben noto da altre piattaforme. I talk/contributi che hanno ricevuto il maggior numero di voti vengono selezionati per l'evento.

Un paio di giorni fa ho proposto di valutare questo meccasnimo nell'ambito del PGDay.IT. Da tempo sono sostenitore di una call-for-papers piu' aperta e con selezione maggiormente trasparente rispetto a quanto è avvenuto nelle ultime edizioni. Anzi, a dire il vero ho anche proposto piu' volte di fare un "speaker fight" del poveraccio addirittura per il keynote, proponendo di chiedere alla community chi fosse interessato a fare un keynote speech invece che andare su singolo invito diretto.

Ora sistemi come quello qui descritto hanno, ovviamente, i loro svantaggi: per esempio si potrebbe votare molto un talk tenuto da un perfetto incompetente che risulterebbe in uno speech di pessima qualità, trascurando magari talk meno "accattivanti" ma di sicuro successo ed impatto.
E forse alcune persone non vogliono selezionare di propria volontà i talk, quanto lasciare che siano gli organizzatori a "stupirli" con contenuti all'altezza di stimolare la curiosità e l'intelletto.
Tuttavia è difficile rimanere in un ambito o nell'altro se non si hanno dati alla mano circa il gradimento delle precedenti edizioni (questione che spesso ho sollevato).

Personalmente ritengo che aprire almeno una porzione del PGDay.IT ad un sistema di votazione diretta possa dare quella spinta ad autori e partecipanti per sentirsi maggiormente coinvolti e, soprattutto, per poter decidere il livello dei contenuti da visionare, garantendo quindi una maggiore partecipazione (almeno in teoria).
Se poi il tutto viene accompagnato anche da un feedback sui talk, si può avere una base dati abbastanza oggettiva che possa permettere un evento migliore ad ogni edizione.

Per sessioni interattive penso che un sistema di gradimento anticipato sia fondamentale: organizzare una sessione interattiva (es. ITPUG-Lab) non è semplice e rischia di portare via risorse (sia organizzatori che partecipanti) dalle track della conferenza. Occorre quindi essere certi del gradimento e della partecipazione alla sessione.

Insomma, una sfida interessante e uno spunto per i prossimi organizzatori dell'evento perché si possa sempre migliorare e non "sedimentare" su formule sempre uguali e ripetute.

Quali parte sono "colpite" dalle statistiche PostgreSQL?

Ecco una interessante immagine che rende l'idea di quali parti del complesso e completo sistema di statistiche PostgreSQL. L'immagine mostra quali viste usare a seconda della parte di backend/stack che si vuole monitorare.

Per l'articolo originale si veda qui:

PostgreSQL @ Python

Il legame tra Python e PostgreSQL appare sempre piu' forte.

Se da un lato ITPUG sarà anche per questa edizione media partner della conferenza italiana PyCon 8 , la community PostgreSQL viene citato nella sezione Community per l'internazionale PyCon 2017.