PostgrSQL 9.3&9.4 - DjangoVillage

PostgreSQL 9.3 & 9.4

Matteo Durighetto

Italian PostgreSQL Users Group www.itpug.org www.postgresql.org

Matteo Durighetto - [email protected] - ITPUG.org

http://www.itpug.org/

http://www.postgresql.org/

mailto:[email protected]

Chi sono?

● Speaker/Author:o Matteo Durighettoo DBA @ Miriade S.p.A. o tecnologie db: Oracle, PostgreSQL, MySQL, MSSQL ..o tecnologie os/virtual/cloud: AWS, Vmware,XEN, Linux, *NIX,

Windowso Membro e Vice Presidente ITPUG

Copyright 2012 Miriade S.p.a.Copyright 2012 Miriade S.p.a.Matteo Durighetto - [email protected] - ITPUG.org

WHOAMI ;

http://www.linkedin.com/in/mdotdurighettoatmiriadedotit

http://www.miriade.it/




Chi sono?

● PostgreSQL 9.3 è alla 9.3.4 ( 4 patch minor ) , stable● PostgreSQL 9.4 è alla fase di beta 1, non è stable, ma è possibile già

testare i vostri software con la versione per comprenderne le potenzialità

per testare PostgreSQL 9.4 beta su Debian 7:

deb http://apt.postgresql.org/pub/repos/apt/ wheezy-pgdg main 9.4

Copyright 2012 Miriade S.p.a.Copyright 2012 Miriade S.p.a.Matteo Durighetto - [email protected] - ITPUG.org

Stato attuale sviluppo




PostgreSQL 9.3● Più User Friendly● Più Pluggable● Più Potente● Più Automazione● Più Sicuro● Più veloce nel backup logico● Più veloce il failover

[email protected] - www.postgresql.org - www.miriade.it



● Più Facile1. Pg 9.3 non necessita più la configurazione del SHMMAX, usa ora un’area

di 68kb con il System V ipc, mentre il restante della shared memory è gestita tramite Posix & mmap ipc.

2. Remastering Standby, lo fa automaticamente non necessita la ricostruzione dello standby o manualmente la copia degli archivelog o repmgr:

3. pg_basebackup -r : per preparare un config file dello standby




● Più Pluggable1. Foreign data wrapper in scrittura e lettura: si può integrare con vari

database (mssql, oracle, mondodb..) o vari servizi in modo trasparente (ldap, twitter.. ) in modo tale da poter scrivere o leggere da varie fonti dati come se fossero tabelle locali.

2. JSON: in 9.2 Pg aveva il datatype, adesso ha metodi di estrazione del valore o convertire il valore in array e viceversa ( JSON_EACH ):

http://www.postgresql.org/docs/9.3/static/functions-json.html


http://www.postgresql.org/docs/9.3/static/functions-json.html



● Più Pluggable1. Background Worker: possibilità di creare un background worker che può

accedere alla shared memory ed eseguire una serie di transazioni. Per esempio si può scrivere un processo che analizza l’efficienza degli indici e li ricostruisce poi oppure per accedere ad un’altra tipologia di database:

https://github.com/umitanuki/mongres

● Più Potente1. Updatable View: le view “semplici” sono aggiornabili.2. Lateral JOIN: una subquery può richiamare un oggetto

di un’altra subquery


https://github.com/umitanuki/mongres



● Più Potente

1. SELECT base.nr, multiples.multiple FROM (SELECT generate_series(1,10) AS nr) base,LATERAL ( SELECT multiples.multiple FROM ( SELECT generate_series(1,10) AS b_nr, base.nr * 2 AS multiple ) multiples WHERE multiples.b_nr = base.nr ) multiples;




● Più Automazione

1. Materialized view: Potete creare una view con un segmento di appoggio di cui potete far refresh.

2. DDL trigger / EVENT TRIGGER: potete automatizzare degli event dopo un evento DDL ( DDL_COMMAND_START / DDL_COMMAND_STOP ).




● More Secure

1. Data Page Checksum: permette il riscontro di problematiche di corruzione tramite il calcolo del page checksum (8k). Necessità di essere inizializzato al momento della creazione del cluster.initdb --data-checksums




● Faster Dump

1. Parallel Dump: l’estrazione parallela permette di evitare costose gestioni via script o altro ( è necessario abilitarla)

pg_dump -Fd -j number_of_processes

● Faster Failover

1. Il Failover è meno di un secondo.




PostgreSQL 9.41. Alter system set ..2. Huge Page3. Refresh concurrently materialized view4. Replication slot5. Logical decoding6. Alter tablespace move7. Hypothetical rank & agg function8. Aggregazione ordinata & filtrata9. Updatable view con CHECK




PostgreSQL 9.410.UNNEST array11.pl/pgsql stack trace12.JSONB13.Background workers dinamici14.pg_basebackup tablespace remapping15.GIN index : miglioramenti16.Pg_prewarm : relation




● 1) ALTER SYSTEM SET

E’ ora possibile modificare un parametro del postgresql.conf col comando alter system set .

esempio :alter system set huge_pages=on;

genera o modifica un file chiamato postgresql.auto.conf all’interno della PG_DATA, commentando i relativi parametri sul postgresql.conf. Al riavvio/reload prenderà le modifiche rispetto allo standard.




● 1) ALTER SYSTEM SET

Esempio sulla work mem :

alter system set work_mem=10M ;

select pg_reload_conf();




● 2) HUGE Page

huge page => 2mb vs 4kb ( sistemi x86 , su Itanium son 16mb etc )

1. Permettono di mappare aree più vaste di shared memory con minori puntatori nella cache TLB della cpu, diminuisce quindi l’uso della cpu nel look up della pagina.

2. Le huge page non possono swappare.3. Se si pone il parametro huge_pages a TRY ,alla partenza prova ad allocare

le pagine ma in caso switcha a paine normali, se si pone ad ON e le pagine non sono sufficienti, il postgresql non parte.




● 2) HUGE Page

1. impostazione 20GB huge pages:2. /etc/sysctl.conf aggiungere vm.nr_hugepages=50003. sysctl -p4. alter system set huge_pages = ‘on’ ## se si vuole forzarle, default è TRY5. pg_ctl reload -D $PG_DATA o service postgresql reload ## debian




● 3) Refresh Materialized View concurrently

1. creazione indice univoco sulla materialized view .2. REFRESH MATERIALIZED VIEW nomeview CONCURRENTLY ;

In questo modo le query sulla materialized view non vengono bloccate.

Come avviene ? tramite un delete della tabella della materialized view e un inserimento del risultato della query.




● 3) Refresh Materialized View concurrently

Unendo questo tipo di refresh ai trigger si può ottenere un refresh on commit (per il caso di truncate, se contemplato va aggiunto un altro trigger ) :




● 4) Replication Slot

Problema: se lo standby è stato posto in fase di maintenance, quando lo riattiverete è possibile che il master abbia esaurito il numero di checkpoint segment della ritenzione :1) ripristinate i checkpoint segment mancanti sullo standby nella directory archive2) ricostruite lo standby

Dalla 9.4 non serve più perchè potete creare il replication slot





creazione slot di replicazione [ N.B. manterrà i checkpoint segment necessari nella XLOG ! ]:

select pg_create_physical_replication_slot('slot01');

verifica:

SELECT * FROM pg_replication_slots;

aggiungere nel recovery.conf : primary_slotname = ‘slot01’





creazione slot di replicazione :

select pg_create_physical_replication_slot('slot01');

verifica:

SELECT * FROM pg_replication_slots;

aggiungere nel recovery.conf : primary_slotname = ‘slot01’




● 5) Logical Decoding

Gli slot possono essere associati ad un replica logica tramite plugin (test_deconding):

select pg_create_logical_replication_slot(‘logslot01’,’test_deconding’);

una volta creato lo slot che viene associato ad un db, si può procedere all’estrazione delle informazioni dal xlog.





Visione delle informazioni :

select pg_logical_slot_peek_changes(‘logslot0’,NULL,NULL);

Estrazione delle informazioni e pulizia coda :

select pg_logical_slot_get_changes(‘logslot0’,NULL,NULL);





Esempio di return del dato ( N.B. attualmente non traccia le DDL ! ) :


SCN/XID Numero transazione Istruzione DML




Formato DML ( per il plugin test_decoding ) :

“tipologia_oggetto schema.nomeoggetto: DML: nomecolonna[tipologia colonna]: valore “

ovviamente si possono avere concatenati più:nomecolonna1[tipologia colonna1]: valore1 nomecolonna2[tipologia colonna2]: valore2 nomecolonna3[tipologia colonna3]: valore3 … nomecolonnaN[tipologia colonnaN]: valoreN




● 6) Alter tablespace move

Dalla 9.4 è possibile muovere tutti gli oggetti da una tablespace ad un’altra dello stesso cluster. Attenzione: è single thread.

ALTER TABLESPACE name MOVE { ALL | TABLES | INDEXES | MATERIALIZED VIEWS } [ OWNED BY role_name [, ...] ] TO new_tablespace [ NOWAIT ]




● 7) Hypothetical Aggregate Function

select RANK(200) WITHIN GROUP ( ORDER BY x ) from ( values ( 0),(10),(20),(100),(500),(5),(100) ) t(x) ;

permettono il calcolo di rank o dense_rank etc di un valore ipotetico rispetto all’ordinamento di una colonna ed un set di valori derivanti da una tabella o da una collezione di valori.




● 7) Hypothetical Aggregate Function

tips : creare indice su colonna ordinate

create index idx01_t1 on t1(x);

select RANK(100) WITHIN GROUP ( ORDER BY x ) from t1 ; ⇒ sequential scan della tabella

select RANK(100) WITHIN GROUP ( ORDER BY x ) from t1 where x <=100 ; ⇒ index only scan con filtro




● 8) Aggregazione ordinata e filtrata

select paese, sum(produzione),sum(produzione) FILTER ( where tipo_produzione=1 ), sum(produzione) FILTER ( where tipo_produzione=2 ) from fact01 group by paese ;

Con l’opzione FILTER è possibile filtrare la funzione aggregato relativa solo al calcolo di quel campo, evitando i case etc.





Funzioni :

mode() => valore più frequentepercentile_disc() => calcolo il percentile restituendo il valore discreto della popolazionepercentile_cont() => fa una interpolazione lineare e restituisce il valore ipotetico che rappresenta il percentile relativo alla popolazione





Sintassi :

SELECT sito, percentile_disc(0.4) WITHIN GROUP (ORDER BY prod)from fact01 group by sito;

ovviamente possia combinare le opzioni :SELECT sito, percentile_disc(0.4) WITHIN GROUP (ORDER BY prod)FILTER ( WHERE tipoproduzione=1 )from fact01 group by sito;




● 9) Updatable view con CHECK

Si può ora definire una view updatabile con controlli sulla where condition , in modo tale che gli update non vadano a violare tali condizioni :

create view vx as select id_prodotto, sum(quantita), avg(costo), sum (quantita*costo) as totalefrom fact01 where id_prodotto is not nullWITH CHECK OPTION;




● 10) UNNESTPossiamo fare l’unnesting degli array es. se definiamo una tabella t3( id int, b int[]) :




● 11) PL/PGSQL stack trace

CREATE FUNCTION teststack() RETURNS integer AS $$DECLAREstack text ;BEGINGET DIAGNOSTICS stack = PG_CONTEXT ;RAISE NOTICE E'--- Call Stack ---\n%', stack ;RETURN 1 ;END;$$ LANGUAGE plpgsql ;




● 11) PL/PGSQL stack trace


Identifica la riga della funzione che ha dato eccezione



● 12) JSONB

Introdotto un nuovo formato binario del JSON , denominato JSONB, più efficiente nello storing del dato. Infatti il json veniva storato come una stringa, mentre il jsonb è di tipo binario.

Sono state inoltre introdotte una serie di funzioni relative al jsonb e una serie di operatori .




● 12) JSONB

tipo dato :

‘{“key1”:”value”,”key2”:valuenumber, .. }’::jsonb

operatori :

-> estrae l’array o la chiave

- -> estrae l’array o la chiave in formato testo senza apici “




● 12) JSONB

esempio :




● 12) JSONB

regole di filtro :

jsonb1 @> jsonb2 => jsonb1 contiene jsonb2jsonb1 <@ jsonb2 => jsonb2 contiene jsonb1jsonb1 = jsonb2 => jsonb1 = jsonb2jsonb1 ? key => la chiave esiste nel jsonb1 ?jsonb1 ?| array[key1,key2] => una delle chiavi esiste nel jsonb1 ?jsonb1 ?& array[key1,key2] => tutte le chiavi esistono nel jsonb1 ?




● 12) JSONB

possibilità di indicizzarli coi gin :




● 12) JSONB

funzioni per esplodere i jsonb ( jsonb_each_text )




● 13) Background worker dinamici

Si possono costruire dei worker dinamici e sono registrabili e attivabili dinamicamente e non più solo al restart




● 14) pg_basebackup remapping

Introdotta l’opzione t :

pg_baebackup … -T OLDDIR=NEWDIR

potete quindi fare un backup rimappandola directory della tablespace.




● 15) GIN Index miglioramenti

*) Riduzione spazio del 40% , sostanzialmente ora vengono salvati i delta [che sono varbyte e occupano da 1 a 6 byte) e non più tutti gli offset :overhead = 6 byteKEY = 7 byte block_id = 4 byte , offest=2 byte

<9.4 : overhead KEY ( block_id, offset) ( block_id, offset) ( block_id, offset) ( block_id, offset) ( block_id, offset) ( block_id, offset)>=9.4: overhead KEY ( block_id, offset) Delta1 Delta2 ..





Nel peggiore dei casi occupano la stessa quantità di spazio nel migliore dei casì però si ottiene così un -40% :

<9.4 6+7+(6*4) = 37 byte >=9.4 6+7+(6*1)+(3*1) = 22 byte





Altra innovazione sono i posting trees , ovvero quando una pagina dei gin index non è più sufficiente a contenere una tupla dell’indice allora viene creato un posting tree compresso .

N.b. se farete upgrade con pg_upgrade, per ottenere i benefici dovrete reindicizzare!




● 16) PG_PREWARM

permette il caricamento in cache db o os di un oggetto, utile dopo un riavvio del db o per stabilizzare la cache.

create extension pg_prewarm ;

select pg_prewarm(‘nomeoggetto’); -- ritorna il numero di pagine caricate.




● 16) PG_PREWARM

metodi : prefetch , read, buffer #default

prefetch : lettura asincrona , popola cache filesystemread : lettura sincrona , popola cache filesystembuffer : popola la cache del db.

select pg_prewarm(‘nomeoggetto’,’prefetch’);




AttribuzioneNon commercialeCondividi allo stesso modo4.0 Italia

http://creativecommons.org/licenses/by-nc-sa/3.0/it/Copyright 2014 Miriade S.p.A. - http://www.miriade.it

Copyright 2012 Miriade S.p.a.

Grazie per l'attenzione

Copyright 2012 Miriade S.p.a. [email protected]

License

www.itpug.org - www.postgresql.org - www.miriade.it







Technology

PostgrSQL 9.3&9.4 - DjangoVillage