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 - m.durighetto@miriade.it - ITPUG.org

Chi sono?
● Speaker/Author:
o Matteo Durighetto
o DBA @ Miriade S.p.A.
o tecnologie db: Oracle, PostgreSQL, MySQL, MSSQL ..
o tecnologie os/virtual/cloud: AWS, Vmware,XEN, Linux, *NIX,
Windows
o Membro e Vice Presidente ITPUG
Copyright 2012 Miriade S.p.a.Copyright 2012 Miriade S.p.a.
WHOAMI ;

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.
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
m.durighetto@miriade.itwww.itpug.org - www.postgresql.org - www.miriade.it

● Più Facile
1. 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:
1. pg_basebackup -r : per preparare un config file dello standbym.durighetto@miriade.itwww.itpug.org - www.postgresql.org - www.miriade.it

● Più Pluggable
1. 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.
1. 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

● Più Pluggable
1. 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ù Potente
1. Updatable View: le view “semplici” sono aggiornabili.
2. Lateral JOIN: una subquery può richiamare un oggetto
di un’altra subquery

● 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.
1. 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.4
1. Alter system set ..
2. Huge Page
3. Refresh concurrently materialized view
4. Replication slot
5. Logical decoding
6. Alter tablespace move
7. Hypothetical rank & agg function
8. Aggregazione ordinata & filtrata
9. Updatable view con CHECK

PostgreSQL 9.4
10.UNNEST array
11.pl/pgsql stack trace
12.JSONB
13.Background workers dinamici
14.pg_basebackup tablespace remapping
15.GIN index : miglioramenti
16.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=5000
3. sysctl -p
4. alter system set huge_pages = ‘on’ ## se si vuole forzarle, default è TRY
5. 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
archive
2) 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ù frequente
percentile_disc() => calcolo il percentile restituendo il valore discreto della
popolazione
percentile_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 totale
from
fact01
where id_prodotto is not null
WITH CHECK OPTION;

● 10) UNNEST
Possiamo 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 $$
DECLARE
stack text ;
BEGIN
GET 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 jsonb2
jsonb1 <@ jsonb2 => jsonb2 contiene jsonb1
jsonb1 = jsonb2 => jsonb1 = jsonb2
jsonb1 ? 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 byte
KEY = 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 filesystem
read : lettura sincrona , popola cache filesystem
buffer : popola la cache del db.
select pg_prewarm(‘nomeoggetto’,’prefetch’);

Attribuzione
Non commerciale
Condividi allo stesso modo
4.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. m.durighetto@miriade.it
License
www.itpug.org - www.postgresql.org - www.miriade.it

PostgrSQL 9.3&9.4 - DjangoVillage

More Related Content

Similar to PostgrSQL 9.3&9.4 - DjangoVillage (20)

More from Miriade Spa (15)

PostgrSQL 9.3&9.4 - DjangoVillage