Jörg Brühe on FromDual GmbH

Ecco alcuni dati chiave: CPU: 2 socket x 24 core x 2 thread = 96 vCore, 756 G RAM, 2 x 10 Tbyte PCIe SSD in RAID-10 e 7 Tbyte di dati, diverse migliaia di clienti, in forte crescita.

Il throughput attuale: 1 M SELECT/min, 56 k INSERT/min, 44 k UPDATE/min , 7 k DELETE/min in media su 30 giorni. Tendenza in forte aumento. Applicazione e query non ottimizzate in modo coerente. Configurazione del database: “state of the art” non verificata con benchmark. Utilizzo della CPU circa il 50% in media, con picchi superiori. Il sistema I/O ha ancora margini di miglioramento.

Il cliente raccoglie dati di posizione e altri dati relativi ai dispositivi e li memorizza nel database. Si tratta quindi di un classico problema IoT (con serie temporali, tabella clusterizzata per indice, ecc.).

La domanda che ha posto è: qual è il modo più veloce per copiare i dati da una tabella (dati in sospeso, una sorta di coda) a un’altra tabella (dati finali, per cliente)?

Il flusso di dati è più o meno il seguente:

+------------+
| IoT Device |--+
+------------+ \
 \ +-----+
+------------+ \ | AS | +--------------+ Processing +------------+
| IoT Device |------+-->| |-->| Pending data |------------->| Final data |
+------------+ / | 400 | +--------------+ of data +------------+
 / +-----+
+------------+ /
| IoT Device |--+
+------------+

Erano disponibili 3 diverse varianti per copiare i dati.

Variante 1: `INSERT` e `DELETE` (forma più semplice)

La variante più semplice è INSERT e DELETE. Questa variante è particolarmente problematica perché MariaDB/MySQL e PostgreSQL hanno AUTOCOMMIT attivato di default (qui, qui, qui et qui).

Per chiarire meglio il concetto, ecco un po’ di pseudocodice:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 foreach ( row ) {
 INSERT INTO final;
 -- implicit COMMIT
 DELETE FROM pending WHERE id = row[id];
 -- implicit COMMIT
 }
}

Se vogliamo copiare 20 k righe, questa variante causa: 40 k COMMIT (fsync) e 42 k roundtrip di rete!

Variante 2: `START TRANSACTION` e `INSERT` e `DELETE`

Questa variante viene utilizzata dagli sviluppatori di database più esperti. Ecco il codice pseudocodice corrispondente:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 foreach ( row ) {
 INSERT INTO final;
 DELETE FROM pending WHERE id = row[id];
 }
 COMMIT;
}

Se in questo esempio vogliamo copiare 20 k righe, questa variante genera solo 2 k COMMIT (fsync)! Quindi 20 volte meno! Ma in cambio 46 k roundtrip di rete (10% in più).

Variante 3: `START TRANSACTION` e `INSERT` e `DELETE` ottimizzati

Questa variante è leggermente più complessa dal punto di vista della programmazione. Viene utilizzata quando si desidera avvicinarsi il più possibile ai limiti del possibile. Ecco il pseudocodice corrispondente:

// 20k rows
for (i = 1; i <= 2000; i++) {

 SELECT * FROM pending LIMIT 10;
 START TRANSACTION;
 INSERT INTO final (), (), (), (), (), (), (), (), (), ();
 DELETE FROM pending WHERE id = IN (...);
 COMMIT;
}

Anche questa terza variante genera solo 2 k COMMIT (fsync) con 20 k righe, ma evita il ciclo delle istruzioni INSERT e DELETE nel database. Da un lato risparmiamo roundtrip di rete (solo 10 k) e cicli CPU sul database (che sono difficili da scalare) per l’analisi delle query.

Configurazione del test

Per testare il tutto, abbiamo preparato un piccolo script: load_data.php

Preparazione ed esecuzione con MariaDB/MySQL

Con i seguenti comandi è possibile eseguire questi test autonomamente:

SQL> CREATE DATABASE test;
SQL> CREATE USER 'app'@'127.0.0.1' IDENTIFIED BY 'secret';
SQL> GRANT ALL ON *.* TO 'app'@'127.0.0.1';

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=mysql --database=test --host=127.0.0.1 --port=3306 --user=app --password=secret --clean-up

Ognuno può elaborare i valori misurati con lo script di test corrispondente.

Preparazione ed esecuzione con PostgreSQL

È possibile eseguire questi test autonomamente utilizzando i seguenti comandi:

postgres# CREATE DATABASE test;
postgres# CREATE USER app PASSWORD 'secret';
postgres# GRANT ALL ON DATABASE test TO app;
postgres# GRANT ALL ON SCHEMA public TO app;

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --prepare

$ for i in $(seq 5) ; do
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=1
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=2
 ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --run --variant=3
done

$ ./load_data.php --database-type=postgresql --database=test --host=127.0.0.1 --port=5432 --user=app --password=secret --clean-up

Ognuno può elaborare i valori misurati utilizzando lo script di test corrispondente.

Risultati

Per evitare discussioni inutili, abbiamo elencato qui “solo” le prestazioni relative (tempo di esecuzione), come fa ultimamente anche MarkC. I nostri valori misurati possono essere messi a disposizione bilateralmente. Tuttavia, possono essere facilmente riprodotti con lo script di test.

Meno è meglio:

	Variante 1	Variante 2	Variante 3
MariaDB 11.8, avg(5)	100.0%	7.5%	6.2%
PostgreSQL 19dev, avg(5)	100.0%	11.2%	7.0%

Attenzione: i valori di MariaDB/MySQL e PostgreSQL NON sono direttamente comparabili!

Ed ecco la valutazione grafica:

Osservazioni

Con dischi più veloci, la differenza tra 1 e 2/3 probabilmente non sarebbe stata così significativa. I test effettuati presso il cliente hanno mostrato “solo” una differenza di circa 5 volte (anziché da 9 a 16 volte).

Ci sono sicuramente altri modi per ottimizzare ulteriormente questo processo di caricamento. Mi vengono in mente:

INSERT INTO ... SELECT * FROM
LOAD DATA INFILE/COPY, se possibile
Prepared Statements
Server side Stored Language (SQL/PSM, PL/pgSQL, …) :-(
PDO-Fetch dei risultati?
etc.

Forse dovrei procurarmi un profiler (Xdebug o xhprof)?

Altri contributi

Questa pagina è stata tradotta utilizzando deepl.com.

MariaDB ha compromesso il concetto di buffer pool configurabile dinamicamente!

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 09 Feb 2026 19:14:00 +0100

Descrizione del problema

MySQL ha introdotto il buffer pool InnoDB configurabile dinamicamente con la versione 5.7.5 nel settembre 2014 (qui e qui):

The innodb_buffer_pool_size configuration option can be set dynamically using a SET statement, allowing you to resize the buffer pool without restarting the server. For example:

mysql> SET GLOBAL innodb_buffer_pool_size=402653184;

MariaDB 10.2.2 ha adottato questa funzione nel settembre 2016 (fonte):

InnoDB was merged from MySQL-5.7.14 (XtraDB is disabled in MariaDB-10.2.2 pending a similar merge)

Il problema è, da un lato, che questa funzione ora non funziona più come prima e non funziona più come previsto. D’altra parte, nella primavera del 2025 hanno modificato il comportamento all’interno di una serie di release principali (LTS), cosa che a mio parere è assolutamente inaccettabile (fonte):

From MariaDB 10.11.12 / 11.4.6 / 11.8.2, there are significant changes to the InnoDB buffer pool behavior.

Inoltre, la descrizione è piuttosto scarsa (fonte):

decreasing innodb_buffer_pool_size at runtime does not release memory (MDEV-32339)

reorganise innodb buffer pool (and remove buffer pool chunks) (MDEV-29445)

The Linux memory pressure interface, which could previously not be disabled and could cause performance anomalies, was rewritten and is disabled by default. (MDEV-34863)

Server crashes when resizing default innodb buffer pool after setting innodb-buffer-pool-chunk-size to 1M (MDEV-34677)

Nel relativo worklog (MDEV-36197), MarkoM descrive anche un altro comportamento:

innodb_buffer_pool_size_auto_max (my proposal for this task) would set the maximum for the automation (default: 0 to disable the logic).

che a mio parere sarebbe stato molto più sensato.

Come funzionava prima?

Come funzionava prima con MariaDB e come funziona ancora oggi con MySQL:

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 134217728 |
+-------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = @@innodb_buffer_pool_chunk_size * 128;

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size';
+-------------------------------+-----------+
| Variable_name | Value |
+-------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 2097152 |
| innodb_buffer_pool_size | 268435456 |
+-------------------------------+-----------+

Quindi tutto OK. Funziona come previsto e come al solito.

Cosa fa MariaDB oggi?

Cosa succede oggi con MariaDB:

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

SQL> SET GLOBAL innodb_buffer_pool_size = 256*1024*1024;
Query OK, 0 rows affected, 1 warning (0.000 sec)

SQL> show warnings;
+---------+------+----------------------------------------------------------------+
| Level | Code | Message |
+---------+------+----------------------------------------------------------------+
| Warning | 1292 | Truncated incorrect innodb_buffer_pool_size value: '268435456' |
+---------+------+----------------------------------------------------------------+

SQL> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool%size%';
+----------------------------------+-----------+
| Variable_name | Value |
+----------------------------------+-----------+
| innodb_buffer_pool_chunk_size | 0 |
| innodb_buffer_pool_size | 134217728 |
| innodb_buffer_pool_size_auto_min | 134217728 |
| innodb_buffer_pool_size_max | 134217728 |
+----------------------------------+-----------+

Niente! Nemmeno un errore, solo un avviso. E se non guardo attentamente, non mi accorgo nemmeno che qualcosa non ha funzionato.

Nel log degli errori di MariaDB c’è scritto:

[Note] InnoDB: Memory pressure event disregarded; innodb_buffer_pool_size=128m, innodb_buffer_pool_size_auto_min=128m

Se poi si fa una ricerca, si scopre che qui è cambiato qualcosa: Buffer Pool Changes e si prova intuitivamente:

SQL> SET GLOBAL innodb_buffer_pool_size_max = 256*1024*1024;
ERROR 1238 (HY000): Variable 'innodb_buffer_pool_size_max' is a read only variable

Ma non funziona.

Ciò significa che è necessario riavviare il database! E questo forse proprio nel momento in cui non si ha affatto bisogno di riavviare e questa funzione sarebbe necessaria…

Nella documentazione si legge anche (fonte):

Default Value: specified by the initial value of innodb_buffer_pool_size, rounded up to the block size of that variable. See the section about buffer pool changes in MariaDB 10.11.12, 11.4.6, and 11.8.2.

e (fonte):

If innodb_buffer_pool_size_max is 0 or not specified, it defaults to the innodb_buffer_pool_size value.

Ciò significa che devo riflettere in anticipo su quanto deve essere grande innodb_buffer_pool_size_max e solo dopo posso correggere durante il funzionamento, se me ne sono dimenticato o ho valutato male.

A mio parere, questo è un completo passo indietro dal punto di vista operativo. Probabilmente si tratta di nuovo di un’implementazione per alcune soluzioni cloud-only as a Service (Enterprise?).

Il mio suggerimento è: o, come proposto in MDEV, 0 dovrebbe disattivare questa funzione e il comportamento dovrebbe rimanere come prima, oppure il valore predefinito dovrebbe essere impostato al 75% della dimensione della RAM, come fa innodb_dedicated_server in MySQL.

Mi sono permesso di aprire un bug qui: New InnoDB Buffer Pool autosize feature not so optimal implemented.

FedericoR ha gentilmente consigliato il seguente link: Issues with new buffer pool configuration in MariaDB Minors (10.11.12/13/14, 11.4.6/7/8, 11.8.2/3). A quanto pare non sono l’unico a cui questa modifica ha dato fastidio…

Come funziona PostgreSQL?

PostgreSQL al momento non è (ancora) in grado di modificare shared_buffers in modo dinamico. Il valore predefinito è solitamente 128M. Qui vale la regola empirica, simile a MyISAM, del 25-40% della RAM. Tuttavia, la mancanza di questa funzione non è probabilmente così grave in PostgreSQL, poiché PostgreSQL fa molto affidamento sulla cache del filesystem, in modo simile a MyISAM.

Fonte: Resource Consumption

Commenti

Vedi qui.

Questa pagina è stata tradotta utilizzando deepl.com.

Quanto spazio occupa NULL?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 16:15:00 +0100

Durante l’ultima consulenza presso il cliente, questi mi è venuto incontro raggiante dicendomi che aveva seguito il mio consiglio e aveva modificato tutte le colonne Primary Key da BIGINT (8 byte) a INT (4 byte) e che questo aveva portato grandi vantaggi! Il suo database MySQL 8.4 era ora più piccolo di 750 Gbyte (da 5,5 Tbyte). Fantastico!

E sì, so che questo contraddice le raccomandazioni di alcuni dei miei colleghi PostgreSQL (qui e qui). Nel mondo MySQL si dà più importanza a queste cose (fonte):

Use the most efficient (smallest) data types possible. MySQL has many specialized types that save disk space and memory. For example, use the smaller integer types if possible to get smaller tables

Inoltre, InnoDB funziona in modo leggermente diverso (tabella clusterizzata dell’indice e chiave primaria in tutte le chiavi secondarie) rispetto a PostgreSQL (tabella heap, indici con puntatore di riga (ctid)).

Ma in realtà non è questo il punto. Subito dopo mi ha chiesto se riempire le colonne di tipo DOUBLE (8 byte, in PostgreSQL DOUBLE PRECISION) con NULL avrebbe portato a un risparmio di spazio o se fosse meglio eliminare subito le colonne. La mia prima risposta istintiva per DOUBLE è stata: NULL è utile, seguito da OPTIMIZE TABLE (in PostgreSQL VACUUM FULL). Il secondo pensiero è stato però: DOUBLE è un tipo di dati fisso più lungo, questo vale anche con NULL o solo per i tipi di dati con lunghezza variabile? La prudenza non è mai troppa! Prima di tutto, consulta il manuale…

E lì c’è scritto (fonte):

Declare columns to be NOT NULL if possible. It makes SQL operations faster, by enabling better use of indexes and eliminating overhead for testing whether each value is NULL. You also save some storage space, one bit per column. If you really need NULL values in your tables, use them. Just avoid the default setting that allows NULL values in every column.

e (fonte):

The variable-length part of the record header contains a bit vector for indicating NULL columns. … Columns that are NULL do not occupy space other than the bit in this vector. The variable-length part of the header also contains the lengths of variable-length columns. Each length takes one or two bytes, depending on the maximum length of the column. If all columns in the index are NOT NULL and have a fixed length, the record header has no variable-length part.

Prova con MariaDB/MySQL

Configurazione di prova

In qualche modo la descrizione mi sembra un po’ troppo complicata. Forse un piccolo schizzo potrebbe aiutare? Allora facciamo una prova:

SQL> -- DROP TABLE IF EXISTS tracking;

SQL> CREATE TABLE tracking (
 id INT UNSIGNED NOT NULL PRIMARY KEY AUTO_INCREMENT
, d0 DOUBLE, d1 DOUBLE, d2 DOUBLE, d3 DOUBLE, d4 DOUBLE
, d5 DOUBLE, d6 DOUBLE, d7 DOUBLE, d8 DOUBLE, d9 DOUBLE
);

SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
SQL> INSERT INTO tracking SELECT NULL, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

Sia in MariaDB che in MySQL, la tabella ha una dimensione di circa 1,8 GB con 16 milioni di righe. Poiché queste informazioni sono indicate in modo molto impreciso in INFORMATION_SCHEMA, controlliamo il file system:

MariaDB 11.8:

SQL> system ls -l tracking.ibd
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL 8.4:

SQL> system ls -l tracking.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Deframmentazione della tabella

Quindi “deframmentiamo” la tabella con il comando OPTIMIZE TABLE:

SQL> OPTIMIZE TABLE tracking;
+---------------+----------+----------+-------------------------------------------------------------------+
| Table | Op | Msg_type | Msg_text |
+---------------+----------+----------+-------------------------------------------------------------------+
| test.tracking | optimize | note | Table does not support optimize, doing recreate + analyze instead |
| test.tracking | optimize | status | OK |
+---------------+----------+----------+-------------------------------------------------------------------+

Attenzione: la tabella viene copiata una volta! Quindi è necessario il doppio dello spazio su disco per un breve periodo! Lo si può osservare chiaramente mentre il comando OPTIMIZE TABLE è in esecuzione:

MariaDB:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 '#sql-alter-d57-8c.frm'
-rw-rw---- 1 mysql mysql 968884224 Feb 7 10:39 '#sql-alter-d57-8c.ibd'
-rw-rw---- 1 mysql mysql 1206 Feb 7 10:28 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 10:32 tracking.ibd

MySQL:

$ watch -d -n 1 'ls -l trac* \#*'
-rw-r----- 1 mysql mysql 369098752 Feb 7 10:40 #sql-ib1594-4164062678.ibd
-rw-r----- 1 mysql mysql 1929379840 Feb 7 10:33 tracking.ibd

Il risultato è però sorprendente! In MariaDB la tabella è rimasta più o meno della stessa dimensione:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:39 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:39 tracking.ibd

In MySQL, invece, dopo la “deframmentazione” la tabella è addirittura cresciuta di circa il 14%:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:41 tracking.ibd

Se eseguiamo nuovamente il comando OPTIMIZE TABLE, la dimensione rimane costante sia in MariaDB che in MySQL:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:46 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 10:48 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 10:48 tracking.ibd

Prova 1: riempire con `NULL`

Ora sovrascriviamo i valori con NULL:

SQL> UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

Dopo questo passaggio, le dimensioni dei file sono addirittura aumentate leggermente:

MariaDB (+1.3%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 10:49 tracking.frm
-rw-rw---- 1 mysql mysql 1937768448 Feb 7 11:04 tracking.ibd

MySQL (+0.2%):

-rw-r----- 1 mysql mysql 2202009600 Feb 7 11:04 tracking.ibd

Successivamente, deframmentiamo nuovamente la tabella con il comando OPTIMIZE TABLE. Come previsto, le tabelle si riducono.

MariaDB (al 23%):

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:09 tracking.frm
-rw-rw---- 1 mysql mysql 448790528 Feb 7 11:10 tracking.ibd

MySQL (al 24%):

-rw-r----- 1 mysql mysql 520093696 Feb 7 11:10 tracking.ibd

Un nuovo OPTIMIZE TABLE non apporta più alcuna modifica alla dimensione del file…

Prova 2: cancellazione delle colonne

Ora proviamo di nuovo con il comando DROP COLUMN. La situazione di partenza è la stessa descritta sopra:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:15 tracking.frm
-rw-rw---- 1 mysql mysql 1933574144 Feb 7 11:18 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 1929379840 Feb 7 11:19 tracking.ibd

Dopo il comando OPTIMIZE TABLE, i valori sono simili a quelli della prima prova:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:20 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:21 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:21 tracking.ibd

Un nuovo OPTIMIZE TABLE non apporta ulteriori modifiche, come sopra:

MariaDB:

-rw-rw---- 1 mysql mysql 1206 Feb 7 11:22 tracking.frm
-rw-rw---- 1 mysql mysql 1912602624 Feb 7 11:23 tracking.ibd

MySQL:

-rw-r----- 1 mysql mysql 2197815296 Feb 7 11:24 tracking.ibd

E ora il secondo tentativo vero e proprio con l’eliminazione delle colonne:

SQL> ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Per prima cosa notiamo che il comando è INSTANTANEOUS, in quanto non apporta alcuna modifica ai dati, ma solo ai metadati. Da un lato questo è positivo, poiché l’influenza sull’applicazione è minima. D’altra parte, ciò significa anche che non si ottiene alcun risparmio di spazio.

Quindi affrontiamo nuovamente il problema con il comando OPTIMIZE TABLE:

MariaDB (al 93%):

-rw-rw---- 1 mysql mysql 925 Feb 7 11:28 tracking.frm
-rw-rw---- 1 mysql mysql 415236096 Feb 7 11:29 tracking.ibd

MySQL (al 92%):

-rw-r----- 1 mysql mysql 478150656 Feb 7 11:28 tracking.ibd

Conclusione

Sia la sostituzione dei valori delle colonne con NULL che la cancellazione delle colonne consentono un notevole risparmio di spazio. La cancellazione delle colonne comporta un risparmio maggiore di circa il 7% rispetto alla sostituzione con NULL. Se possibile dal punto di vista applicativo, è quindi consigliabile cancellare le colonne non più necessarie; se ciò non è possibile, sostituirle almeno con NULL.

Prova con PostgreSQL

Ora esaminiamo il tutto con PostgreSQL.

Configurazione della prova

La configurazione della prova è analoga a quella di MariaDB/MySQL:

postgres=# -- DROP TABLE IF EXISTS tracking;

postgres=# CREATE TABLE tracking (
 id SERIAL PRIMARY KEY
, d0 DOUBLE PRECISION, d1 DOUBLE PRECISION, d2 DOUBLE PRECISION, d3 DOUBLE PRECISION, d4 DOUBLE PRECISION
, d5 DOUBLE PRECISION, d6 DOUBLE PRECISION, d7 DOUBLE PRECISION, d8 DOUBLE PRECISION, d9 DOUBLE PRECISION
);

postgres=# \timing

postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0;
postgres=# INSERT INTO tracking (d0, d1, d2, d3, d4, d5, d6, d7, d8, d9)
 SELECT 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0 FROM tracking;
... bis 16 M rows

Per prima cosa vogliamo sapere quanto è diventata grande la tabella. PostgreSQL sembra conoscere queste informazioni con estrema precisione:

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376856576 | 359 MB | 2340274176 | 2232 MB | 2340798464 | 2232 MB

Poi vogliamo sapere dove si trovano questi file nel filesystem:

postgres=# SELECT oid AS db_oid FROM pg_database WHERE datname = current_database();
 db_oid
--------
 5

postgres=# SELECT oid AS table_oid, relname, relnamespace, relfilenode
 FROM pg_class WHERE relname = 'tracking';
 table_oid | relname | relnamespace | relfilenode
-----------+----------+--------------+-------------
 40965 | tracking | 2200 | 40965

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 WHERE c.relname = 'tracking';
 index_name | index_oid
---------------+-----------
 tracking_pkey | 40970

postgres=# SELECT pg_relation_filepath('tracking');
 pg_relation_filepath
----------------------
 base/5/40965

Dimensioni della tabella e dell’indice nel filesystem:

$ ls -ltr 40965* 40970*
-rw------- 1 mysql mysql 40960 Feb 7 18:33 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:33 40965_fsm
-rw------- 1 mysql mysql 889675776 Feb 7 18:34 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:34 40965
-rw------- 1 mysql mysql 376856576 Feb 7 18:35 40970

*_fsm significa “free space map”
*_vm significa “visibility map”
*.1 significa 2° segmento dell’oggetto (tabella o indice)

PostgreSQL sembra lavorare di default con segmenti di 1 GB e, a differenza di MariaDB/MySQL (INFORMATION_SCHEMA), sembra conoscere con estrema precisione le dimensioni dei propri file. La discrepanza di cui sopra (tra tot_rel_siz e tab_and_idx_siz) può essere spiegata dai file fsm e vm.

L’equivalente PostgreSQL di MariaDB/MySQL OPTIMIZE TABLE è il comando VACUUM FULL:

postgres=# VACUUM FULL tracking;

$ ls -ltr
-rw------- 1 mysql mysql 40960 Feb 7 18:39 40965_vm
-rw------- 1 mysql mysql 499712 Feb 7 18:39 40965_fsm
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40965
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40965.1
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 0 Feb 7 18:39 40975

...

-rw------- 1 mysql mysql 49152 Feb 7 18:39 2704
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2703
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2696
-rw------- 1 mysql mysql 65536 Feb 7 18:39 2674
-rw------- 1 mysql mysql 81920 Feb 7 18:39 2673
-rw------- 1 mysql mysql 98304 Feb 7 18:39 2659
-rw------- 1 mysql mysql 139264 Feb 7 18:39 2658
-rw------- 1 mysql mysql 24576 Feb 7 18:39 2619_fsm
-rw------- 1 mysql mysql 163840 Feb 7 18:39 2619
-rw------- 1 mysql mysql 106496 Feb 7 18:39 2608
-rw------- 1 mysql mysql 491520 Feb 7 18:39 1249
-rw------- 1 mysql mysql 122880 Feb 7 18:39 1247
-rw------- 1 mysql mysql 32768 Feb 7 18:39 2662
-rw------- 1 mysql mysql 114688 Feb 7 18:39 1259
-rw------- 1 mysql mysql 16384 Feb 7 18:39 3455
-rw------- 1 mysql mysql 49152 Feb 7 18:39 2663
-rw------- 1 mysql mysql 1073741824 Feb 7 18:39 40972
-rw------- 1 mysql mysql 889675776 Feb 7 18:39 40972.1
-rw------- 1 mysql mysql 376864768 Feb 7 18:39 40975
-rw------- 1 mysql mysql 0 Feb 7 18:39 40965
-rw------- 1 mysql mysql 0 Feb 7 18:39 40970

La prima cosa che si nota è che PostgreSQL crea molti file e il file “free space map” è scomparso. A differenza di MariaDB/MySQL, i segmenti della tabella sono rimasti della stessa dimensione. Si nota inoltre che la vecchia tabella è “scomparsa” (40965, 40970) e ne è stata creata una nuova (40972 e 40975). Il comando VACUUM FULL in PostgreSQL crea quindi, come in MariaDB/MySQL, una copia dei dati.

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 1963417600 | 1872 MB | 376864768 | 359 MB | 2340282368 | 2232 MB | 2340282368 | 2232 MB

Per capire quali altri file/oggetti sono stati modificati, è utile la seguente query:

postgres=# SELECT c.oid, c.relname, ns.nspname
FROM pg_class AS c
JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 oid | relname | nspname
-------+-----------------------------------+------------
 40965 | tracking | public
 40970 | tracking_pkey | public
 2619 | pg_statistic | pg_catalog
 1247 | pg_type | pg_catalog
 2703 | pg_type_oid_index | pg_catalog
 2704 | pg_type_typname_nsp_index | pg_catalog
 2658 | pg_attribute_relid_attnam_index | pg_catalog
 2659 | pg_attribute_relid_attnum_index | pg_catalog
 2662 | pg_class_oid_index | pg_catalog
 2663 | pg_class_relname_nsp_index | pg_catalog
 3455 | pg_class_tblspc_relfilenode_index | pg_catalog
 2696 | pg_statistic_relid_att_inh_index | pg_catalog
 2673 | pg_depend_depender_index | pg_catalog
 2674 | pg_depend_reference_index | pg_catalog
 1249 | pg_attribute | pg_catalog
 1259 | pg_class | pg_catalog
 2608 | pg_depend | pg_catalog

postgres=# SELECT i.indexrelid::regclass as index_name, i.indexrelid as index_oid, ns.nspname
 FROM pg_index i
 JOIN pg_class c ON i.indrelid = c.oid
 JOIN pg_namespace AS ns ON ns.oid = c.relnamespace
 WHERE c.oid IN (2704, 2703, 2696, 2674, 2673, 2659, 2658, 2619, 2608, 1249, 1247, 40972, 2662, 1259, 3455, 2663, 40975, 40965, 40970)
;
 index_name | index_oid | nspname
-----------------------------------+-----------+------------
 pg_type_typname_nsp_index | 2704 | pg_catalog
 pg_attribute_relid_attnam_index | 2658 | pg_catalog
 tracking_pkey | 40970 | public
 pg_class_relname_nsp_index | 2663 | pg_catalog
 pg_class_tblspc_relfilenode_index | 3455 | pg_catalog
 pg_type_oid_index | 2703 | pg_catalog
 pg_attribute_relid_attnum_index | 2659 | pg_catalog
 pg_statistic_relid_att_inh_index | 2696 | pg_catalog
 pg_depend_depender_index | 2673 | pg_catalog
 pg_depend_reference_index | 2674 | pg_catalog
 pg_class_oid_index | 2662 | pg_catalog

Tentativo 1: riempire con `NULL`

Quindi sovrascriviamo anche i valori delle colonne in PostgreSQL con NULL. Da questo punto in poi non ci occuperemo più del file system, poiché PostgreSQL sembra conoscere con precisione le dimensioni dei file, come abbiamo visto sopra:

postgres=# UPDATE tracking
SET d0 = NULL, d1 = NULL, d2 = NULL, d3 = NULL, d4 = NULL
 , d5 = NULL, d6 = NULL, d7 = NULL, d8 = NULL, d9 = NULL
;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
------------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 2695716864 | 2571 MB | 753696768 | 719 MB | 3449413632 | 3290 MB | 3450101760 | 3290 MB

Qui vediamo che i segmenti della tabella crescono in modo massiccio (+37%), ciò che nella terminologia PostgreSQL viene definito “bloat”. L’implementazione MVCC di PostgreSQL salva sia la versione vecchia che quella nuova della riga “in-place”, ovvero direttamente nella tabella, a differenza di MariaDB/MySQL che salva la versione vecchia nello spazio UNDO e la nuova riga “in-place”. Anche il file dell’indice aumenta in modo significativo (+100%). Dobbiamo ancora approfondire il motivo di questo fenomeno. Inoltre, viene nuovamente creata una “free space map” (differenza tra tot_rel_siz e tab_and_idx_siz).

Un successivo VACUUM FULL riduce la tabella (al 28%) e l’indice (al 50%) rispetto alle dimensioni precedenti:

postgres=# VACUUM FULL tracking;

postgres=# SELECT pg_relation_size('tracking') AS tab_siz
 , pg_size_pretty(pg_relation_size('tracking')) AS tab_siz_prtty
 , pg_indexes_size('tracking') AS idx_siz
 , pg_size_pretty(pg_indexes_size('tracking')) AS idx_siz_prtty
 , pg_relation_size('tracking') + pg_indexes_size('tracking') AS tab_and_idx_siz
 , pg_size_pretty(pg_relation_size('tracking') + pg_indexes_size('tracking')) AS tab_and_idx_siz_prtty
 , pg_total_relation_size('tracking') AS tot_rel_siz
 , pg_size_pretty(pg_total_relation_size('tracking')) AS tot_rel_siz_prtty
;
 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

e anche rispetto alle dimensioni originali, la tabella (al 38%) e l’indice (al 100%) diventano nuovamente più piccoli. Il motivo per cui l’indice è rimasto della stessa dimensione e solo la tabella si è ridotta deve ancora essere studiato…

Tentativo 2: cancellazione delle colonne

Successivamente, le colonne vengono cancellate con DROP COLUMN.

postgres=# ALTER TABLE tracking
 DROP COLUMN d0, DROP COLUMN d1, DROP COLUMN d2, DROP COLUMN d3, DROP COLUMN d4
, DROP COLUMN d5, DROP COLUMN d6, DROP COLUMN d7, DROP COLUMN d8, DROP COLUMN d9
;

Poiché la risposta è arrivata immediatamente, si può presumere che anche questa operazione sia istantanea. Purtroppo non ho trovato nulla al riguardo nella documentazione di PostgreSQL.

Le dimensioni non sono cambiate in modo significativo, cosa che in realtà è prevedibile con un’operazione istantanea. Tuttavia, il fatto che le dimensioni non siano cambiate dopo il comando VACUUM FULL è stato un po’ sorprendente:

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1120010240 | 1068 MB

postgres=# VACUUM FULL tracking;

 tab_siz | tab_siz_prtty | idx_siz | idx_siz_prtty | tab_and_idx_siz | tab_and_idx_siz_prtty | tot_rel_siz | tot_rel_siz_prtty
-----------+---------------+-----------+---------------+-----------------+-----------------------+-------------+-------------------
 742916096 | 709 MB | 376864768 | 359 MB | 1119780864 | 1068 MB | 1119780864 | 1068 MB

Osservazioni

Il locking in PostgreSQL funziona come segue:

VACUUM Sono possibili comandi DML concorrenti simili al comando OPTIMIZE TABLE di MariaDB/MySQL. Il risultato, tuttavia, non è esattamente lo stesso.
VACUUM FULL provoca un blocco ACCESS EXCLUSIVE. Simile a MariaDB/MySQL 5.5 e versioni precedenti con il comando OPTIMIZE TABLE. I comandi DML e SELECT NON sono consentiti.

Fonti

Prove aggiuntive

Invece di 0.0, nelle colonne d0 - d9 è stato inserito NULL. La tabella è rimasta piccola (tot_rel_siz_prtty = 1068 MB). Vale quindi la pena salvare NULL invece di valori fittizi anche in PostgreSQL.
Le colonne d0 - d9 sono state create con DOUBLE PRECISION NOT NULL e riempite con i valori 0.0. Nessun effetto: la tabella è rimasta grande (tot_rel_siz_prtty = 2232 MB).

Questa pagina è stata tradotta utilizzando deepl.com.

Qualcuno sta cancellando i miei segmenti di memoria condivisa!

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sun, 08 Feb 2026 06:27:00 +0100

Quando lavoriamo con PostgreSQL su myEnv, riceviamo regolarmente errori relativi al segmento di memoria condivisa. Esempio:

psql: error: connection to server on socket "/tmp/.s.PGSQL.5433" failed:
FATAL: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

oppure vediamo messaggi simili nel log degli errori di PostgreSQL:

ERROR: could not open shared memory segment "/PostgreSQL.4220847662":
No such file or directory

Essendo un amministratore MariaDB/MySQL, non ho molta familiarità con i problemi relativi alla memoria condivisa (MariaDB/MySQL non funziona con la memoria condivisa). Fortunatamente, una ricerca su Internet ci ha portato su una pista (fonte). Qui si legge:

The documentation of systemd states that this only happens for non-system users. Can you check whether your “postgres” user (or whatever you are using) is a system user?

Utente di sistema Linux

Per prima cosa ho dovuto capire cosa fosse un utente di sistema in Linux. Ho trovato una risposta qui: What’s the difference between a normal user and a system user?.

That is not a technical difference but an organizational decision. E.g. it makes sense to show normal users in a login dialog (so that you can click them instead of having to type the user name) but it wouldn’t to show system accounts (the UIDs under which daemons and other automatic processes run) there.

Lo standard LSB dice: User ID Ranges:

The system User IDs from 0 to 99 should be statically allocated by the system, and shall not be created by applications.
The system User IDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts using useradd.

Sul mio sistema Ubuntu appare come segue:

$ grep SYS_ /etc/login.defs
#SYS_UID_MIN 100
#SYS_UID_MAX 999
#SYS_GID_MIN 100
#SYS_GID_MAX 999

Per l’utente PostgreSQL sarebbe corretto:

$ id postgres
uid=130(postgres) gid=142(postgres) groups=142(postgres),116(ssl-cert)

Ma poiché l’istanza PostgreSQL interessata funziona sotto il nostro myEnv, è diverso:

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

Ora abbiamo due possibilità:

Modifichiamo SYS_UID_MAX e SYS_GID_MAX su 1001 (variante semplice).
Oppure modifichiamo l’UID e il GID del nostro utente dba a meno di 1000.

Variante semplice: modifica di `SYS_UID_MAX` e `SYS_GID_MAX` a 1001

# /etc/login.defs
SYS_UID_MAX 1001
SYS_GID_MAX 1001

Per sicurezza, la macchina è stata riavviata. Tuttavia, ciò non è servito: dopo poco tempo si verificano nuovamente gli stessi errori.

Variante più complessa: modifica dell’`UID` da 1001 a 990

$ cat /etc/passwd
...
polkitd:x:997:997:User for polkitd:/:/usr/sbin/nologin
systemd-coredump:x:998:998:systemd Core Dumper:/:/usr/sbin/nologin
tomcat:x:999:999:Apache Tomcat:/:/sbin/nologin
oli:x:1000:1000:Oli Sennhauser,,,:/home/oli:/bin/bash
dba:x:1001:1001:DBA user:/home/dba:/bin/bash
...

$ id dba
uid=1001(dba) gid=1001(dba) groups=1001(dba)

A tal fine, tutti i processi di questo utente devono essere arrestati!

$ usermod --uid 990 dba
$ groupmod --gid 990 dba

$ find / -user 1001 -exec chown --no-dereference dba {} \;
$ find / -group 1001 -exec chgrp --no-dereference dba {} \;

Il problema sembra essere risolto!

Informazioni aggiuntive

Una fonte citata in precedenza consigliava di impostare i seguenti parametri in systemd-logind:

# /etc/systemd/system/systemd-logind.service.d/override.conf
RemoveIPC=no
RuntimeDirectorySize=1%

Tuttavia, questa misura non è più necessaria, poiché il sistema funziona anche senza questa modifica.

Questa pagina è stata tradotta utilizzando deepl.com.

Caricare file CSV nel database

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 06 Feb 2026 18:04:00 +0100

Recentemente, per un piccolo gioco personale, ho voluto rappresentare su una mappa i luoghi di residenza dei membri della mia associazione (IGOC Mitglieder). Conoscevo gli indirizzi dei membri dell’associazione, ma non le coordinate dei loro luoghi di residenza.

Così mi sono messo alla ricerca delle coordinate e le ho trovate presso l’Ufficio federale di topografia (swisstopo).

I dati sono disponibili in formato CSV. Maggiori dettagli qui: Coordinate delle località svizzere.

Come si caricano questi dati in un database?

Caricamento dei dati con MariaDB/MySQL

MariaDB e MySQL dispongono del comando LOAD DATA INFILE:

SQL> DROP TABLE IF EXISTS wgs84;

SQL> -- SET GLOBAL local_infile = ON; -- Only needed with MySQL

SQL> CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id SMALLINT UNSIGNED
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE
, n DOUBLE
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

SQL> -- TRUNCATE TABLE wgs84;

SQL> LOAD DATA LOCAL INFILE '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
INTO TABLE wgs84
FIELDS TERMINATED BY ';'
LINES TERMINATED BY '\r\n'
IGNORE 1 LINES
;
Query OK, 5713 rows affected
Records: 5713 Deleted: 0 Skipped: 0 Warnings: 0

Successivamente è possibile interrogare i dati nel database:

SQL> SELECT * FROM wgs84 ORDER BY ortschaftsname LIMIT 5;
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| ortschaftsname | plz4 | zusatzziffer | zip_id | gemeindename | bfs_nr | kantonskuerzel | adressenanteil | e | n | sprache | validity |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
| Aadorf | 8355 | 0 | 4672 | Aadorf | 4551 | TG | 96.802 % | 8.903193007810433 | 47.491079014637265 | de | 2008-07-01 |
| Aadorf | 8355 | 0 | 4672 | Elgg | 294 | ZH | 3.198 % | 8.89206766645808 | 47.4933781685032 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Aarau | 4001 | AG | 99.713 % | 8.048148371736266 | 47.38973523857376 | de | 2008-07-01 |
| Aarau | 5000 | 0 | 2913 | Suhr | 4012 | AG | 0.287 % | 8.059410934099922 | 47.383298214804334 | de | 2008-07-01 |
| Aarau | 5004 | 0 | 2932 | Aarau | 4001 | AG | 100 % | 8.060698546432551 | 47.400587704180744 | de | 2008-07-01 |
+----------------+------+--------------+--------+--------------+--------+----------------+----------------+-------------------+--------------------+---------+------------+
5 rows in set

O, per essere più precisi:

SQL> SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
+-------------+-----------+-------------------+--------------------+
| city | city_code | lon | lat |
+-------------+-----------+-------------------+--------------------+
| Aarburg | 4663 | 7.904271716719409 | 47.321443418782955 |
| Aarburg | 4663 | 7.889249714098425 | 47.313536073562474 |
| Aarburg | 4663 | 7.880309179095798 | 47.31255194439023 |
| Adligenswil | 6043 | 8.364849060491428 | 47.07037816052481 |
| Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056 |
| Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134 |
| Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145 |
+-------------+-----------+-------------------+--------------------+
7 rows in set (0.003 sec)

Lascio al gentile lettore o alla gentile lettrice il compito di eliminare i duplicati… :-)

Fin qui tutto bene, passiamo ora alle sottigliezze:

Differenze tra MariaDB e MySQL

La procedura sopra descritta funziona perfettamente con MariaDB 11.4 e 11.8. Con MySQL 8.4 ci sono piccole differenze:

Il primo messaggio di errore che impedisce il caricamento è questo:

ERROR 3948 (42000): Loading local data is disabled; this must be enabled on both the client and server sides

Può essere aggirato in modo relativamente semplice con il comando:

SQL> SET GLOBAL local_infile = ON;

Al prossimo tentativo si fallirà come segue:

ERROR 2068 (HY000): LOAD DATA LOCAL INFILE file request rejected due to restrictions on access.

Questo problema può essere risolto avviando il client MySQL come segue:

$ mysql --local-infile=1 --user=root test

Fonti

MariaDB: LOAD DATA INFILE
MySQL: LOAD DATA Statement

Caricamento dei dati con PostgreSQL

PostgreSQL dispone del comando COPY ... FROM:

postgres=# DROP TABLE IF EXISTS wgs84;

postgres=# CREATE TABLE wgs84 (
 ortschaftsname VARCHAR(32)
, plz4 SMALLINT
, zusatzziffer SMALLINT
, zip_id INT
, gemeindename VARCHAR(32)
, bfs_nr SMALLINT
, kantonskuerzel CHAR(2)
, adressenanteil varchar(8)
, e DOUBLE PRECISION
, n DOUBLE PRECISION
, sprache VARCHAR(8)
, validity VARCHAR(12)
);

postgres=# -- TRUNCATE TABLE wgs84;

postgres=# COPY wgs84
FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
DELIMITER ';'
CSV HEADER
;
COPY 5713

Anche in questo caso otteniamo il risultato previsto nella forma usuale per PostgreSQL:

postgres=# SELECT ortschaftsname AS city, plz4 AS city_code, e AS lon, n AS lat
 FROM wgs84 WHERE plz4 IN (8280, 4663, 6043);
 city | city_code | lon | lat
-------------+-----------+-------------------+--------------------
 Aarburg | 4663 | 7.904271716719409 | 47.321443418782955
 Aarburg | 4663 | 7.889249714098425 | 47.313536073562474
 Aarburg | 4663 | 7.880309179095798 | 47.31255194439023
 Adligenswil | 6043 | 8.36487538940682 | 47.07037794822416
 Kreuzlingen | 8280 | 9.173740257895282 | 47.64491046067056
 Kreuzlingen | 8280 | 9.159171428030783 | 47.654149879509134
 Kreuzlingen | 8280 | 9.204470741840725 | 47.639949130372145
(7 rows)

Fonti

PostgreSQL: COPY

Piccole differenze tra MariaDB/MySQL e PostgreSQL

In linea di principio, il comando di caricamento è completamente diverso nei due mondi di database.

In MariaDB e PostgreSQL i comandi funzionano “out-of-the-box”. MySQL ha integrato due ulteriori barriere di sicurezza.

PostgreSQL non conosce i tipi di dati interi USINGED, quindi è necessario utilizzare il tipo di dati immediatamente superiore (INT), che occupa leggermente più spazio rispetto a MariaDB/MySQL.

Osservazioni

Quando abbiamo eseguito lo stesso test pochi giorni fa, si è verificato un errore durante il caricamento. Sembra quindi che anche la fonte dei dati sia leggermente cambiata…

Non sono riuscito a capire rapidamente se esiste uno standard SQL per questi comandi di caricamento e, in caso affermativo, se MariaDB/MySQL o PostgreSQL sono conformi allo standard.

E naturalmente ci sono anche altri modi per inserire i propri dati CSV nel database…

Gli strumenti mariadb-import/mysqlimport vengono utilizzati se si desidera eseguire l’operazione dalla riga di comando. Anche il CSV Storage Engine può essere utilizzato a questo scopo (per i dettagli vedere qui). Una variante ufficialmente supportata è il motore di archiviazione MariaDB CONNECT con il tipo CSV (vedi qui):

SQL> INSTALL SONAME 'ha_connect';

SQL> CREATE TABLE wgs84_fdw
ENGINE = CONNECT
table_type = CSV
file_name='/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv'
header = 1
sep_char = ';'
quoted = 0;

SQL> INSERT INTO wgs84 SELECT * FROM wgs84_fdw;

A quanto pare, il motore di archiviazione CONNECT di MariaDB non è più supportato?!? Anche lo strumento mydumper/myloader sembra essere in grado di gestire i file CSV.

E naturalmente il tutto può essere risolto anche a livello applicativo…

Con PostgreSQL ci sono le seguenti possibilità:

postgres=# \copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER

quindi dalla shell:

$ psql --user=dba -c "\copy wgs84 FROM '/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv' DELIMITER ';' CSV HEADER"

E la variante tramite Foreign Data Wrapper (FWD). Non l’ho però provata:

postgres=# CREATE EXTENSION postgres_fdw;

postgres=# CREATE SERVER foreign_server
 FOREIGN DATA WRAPPER postgres_fdw
 OPTIONS (
 datasource 'CSV:/tmp/AMTOVZ_CSV_WGS84/AMTOVZ_CSV_WGS84.csv',
 format 'CSV'
 )
;

postgres=# CREATE USER MAPPING FOR local_user
 SERVER foreign_server
 OPTIONS (user 'foreign_user', password 'password')
;

postgres=# CREATE FOREIGN TABLE foreign_table (
 id integer NOT NULL,
 data text
)
 SERVER foreign_server
 OPTIONS (schema_name 'some_schema', table_name 'some_table')
;

Aggiunta

Il tipo di dati MariaDB/MySQL DOUBLE in ProsgreSQL si chiama DOUBLE PRECISION.

Questa pagina è stata tradotta utilizzando deepl.com.

FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 21 Jan 2026 11:36:36 +0100

Servizi neutrali e indipendenti dal produttore
per MariaDB, Galera Cluster e MySQL!

Servizi per MariaDB, Galera e MySQL

Offriamo i seguenti servizi:

Consulenza neutrale e indipendente dal produttore per MySQL, Galera Cluster, MariaDB e Percona Server.
Abbonamenti di assistenza Enterprise per MariaDB, Galera Cluster e MySQL.
Corsi di formazione/seminari su MariaDB, Galera e MySQL per amministratori di database (DBA) e sviluppatori.
Con i nostri servizi remote-DBA vi aiutiamo a gestire i vostri database MariaDB e MySQL critici per l’azienda.
I nostri prodotti software: OpsCenter, Performance Monitor, Backup/Recovery Manager e myEnv vi supportano nella gestione della vostra infrastruttura.

Per ulteriori informazioni, contattateci …

Provate gratuitamente il nostro Monitoring as a Service

Corsi di formazione MariaDB, Galera e MySQL in programma

Per ulteriori informazioni sul nostro programma di formazione, consultate la pagina Corsi di formazione/seminari MariaDB, Galera e MySQL.

' . 'ERROR: Snipped currently unavailable!' . '

' . "\n"; error_log('File: ' . $file . ' does NOT exist.'); } ?>

Notizie FromDual

Per le notizie da e su FromDual, seguiteci su a:

LinkedIn, X / Twitter, Facebook, Bluesky o Mastodon.

Questa pagina è stata tradotta con deepl.com.

Test

oli.sennhauser@fromdual.com (Oli Sennhauser) — Wed, 21 Jan 2026 11:28:01 +0100

Una pagina di prova in tedesco…

Contattare FromDual

oli.sennhauser@fromdual.com (Oli Sennhauser) — Fri, 16 Jan 2026 20:42:00 +0100

Potete contattarci nei seguenti modi:

Indirizzo:	FromDual GmbH Rebenweg 6 CH - 8610 Uster Svizzera
E-mail:	contact@fromdual.com
Telefono:	+41 44 500 58 20	+49 201 853 67 70

Partita IVA/UID:	CHE-301.341.221 MWST
Numero DUNS:	485921436

InnoDB deadlock con SELECT? Non è possibile! O forse sì?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Sat, 25 Nov 2023 18:05:25 +0000

Introduzione

Due punti per iniziare:

Un deadlock è uno stato in cui due transazioni diverse non sono più in grado di continuare a lavorare perché ciascuna transazione detiene un blocco di cui l’altra transazione avrebbe bisogno. Poiché entrambe le transazioni stanno aspettando che l’altra transazione rilasci il proprio blocco, nessuna delle due rilascerà il proprio blocco. E questo durerebbe fino a dopodomani. Per evitare ciò, l’istanza di MariaDB interviene e uccide la transazione che ha svolto meno lavoro. L’applicazione riceve quindi un messaggio di errore di deadlock del tipo:
```
ERROR 1213 (40001): Deadlock found when trying to get lock; try restarting transaction
```
Il mantra generale nell’ecosistema MariaDB è che una SELECT non causa blocchi (eccezione: FOR UPDATE o LOCK IN SHARE MODE) e quindi non può essere parte di un deadlock.

Il problema

Un cliente di lunga data si rivolge al team di DBA remoti di FromDual con la richiesta di spiegare una situazione di deadlock:

Salve team FromDual, Ho bisogno della vostra competenza in materia di deadlock. Quando vi farebbe comodo?

La situazione è la seguente: La transazione 1 consiste in una semplice INSERT. La transazione 2 consiste in una SELECT. Questo non dovrebbe causare un deadlock!

Per prima cosa controlliamo i seguenti punti:

Tutte le tabelle interessate da queste query sono indicizzate correttamente? Sì, lo sono. Le query funzionano tutte perfettamente!
La query SELECT fa forse parte di una transazione più ampia (NON una transazione con auto-commit) e quindi non è la causa effettiva del deadlock? No, non lo è. Si tratta di transazioni con auto-commit.

E adesso? Cosa c’è da dire per chiarire: La SELECT viene inviata con una cadenza molto alta, cioè circa ogni 5 ms!

È chiaro che l’INSERT crea dei blocchi. Viene anche visualizzato. Ma perché il comando SELECT genera dei blocchi? Anche questi vengono visualizzati!

Cerchiamo quindi di scomporre il problema in singoli passaggi.

Modo per risolvere

La query si presenta come segue:

SQL> SET @id = (SELECT id FROM test WHERE id = 3);

Se impacchettiamo questa query in una transazione esplicita, possiamo anche vedere i lock:

SQL> START TRANSACTION;
SQL> SET @id = (SELECT id FROM test WHERE id = 3);

e in una seconda connessione:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:27:09
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 2
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 1
 trx_lock_structs: 2
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 1
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Purtroppo non è possibile vedere di che tipo di blocco (IS) si tratta perché la vista INNODB_LOCKS è vuota.

La soluzione

Se facciamo lo stesso tentativo con delle SELECT “normali”:

SQL> START TRANSACTION; SELECT id FROM test WHERE id = 3;

SQL> START TRANSACTION; SELECT id INTO @id FROM test WHERE id = 3;

NON vediamo nessun blocco:

SQL> SELECT * FROM information_schema.INNODB_TRX<br>G
*************************** 1. row ***************************
 trx_id: 0
 trx_state: RUNNING
 trx_started: 2023-11-19 15:31:35
 trx_requested_lock_id: NULL
 trx_wait_started: NULL
 trx_weight: 0
 trx_mysql_thread_id: 3765
 trx_query: NULL
 trx_operation_state:
 trx_tables_in_use: 0
 trx_tables_locked: 0
 trx_lock_structs: 0
 trx_lock_memory_bytes: 1128
 trx_rows_locked: 0
 trx_rows_modified: 0
 trx_concurrency_tickets: 0
 trx_isolation_level: REPEATABLE READ
 trx_unique_checks: 1
 trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
 trx_is_read_only: 0
trx_autocommit_non_locking: 0

Sembra quindi che il costrutto SET @id = (...) causi questo blocco IS. Il cliente riscrive la sua applicazione e poco dopo riceviamo il seguente messaggio:

Salve team FromDual, Il vostro consiglio è stato azzeccato. Nessun blocco da venerdì a pranzo. Grazie e buon fine settimana.

Ulteriori domande chiarificatrici

MySQL 8.0 si comporta allo stesso modo? Sì, esattamente lo stesso.

Addendum

Il mio caro collega Matthias mi ha dato un’altra idea: che dire delle Stored Procedures e delle Stored Functions di MariaDB?

I due test sono qui:

DELIMITER //

CREATE OR REPLACE PROCEDURE locktestsp (INOUT id INT)
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
END;
//

DELIMITER ;

SET @id = 3;
START TRANSACTION;
CALL locktestsp(@id);
SELECT @id;

SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

e qui:

DELIMITER //

CREATE OR REPLACE FUNCTION locktestsf (IN id INT)
RETURNS CHAR(50) DETERMINISTIC
BEGIN
 SELECT id INTO id FROM test WHERE id = id LIMIT 1;
 RETURN id;
END;
//

DELIMITER ;

START TRANSACTION;
SELECT locktestsf(3);

 SELECT trx_tables_locked, trx_lock_structs, trx_rows_locked FROM information_schema.INNODB_TRX;
+-------------------+------------------+-----------------+
| trx_tables_locked | trx_lock_structs | trx_rows_locked |
+-------------------+------------------+-----------------+
| 0 | 0 | 0 |
+-------------------+------------------+-----------------+

Questa pagina è stata tradotta utilizzando deepl.com.

Ops! Pagina non trovata.

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 01 Jan 0001 00:00:00 +0000

Cosa stai cercando esattamente?

oli.sennhauser@fromdual.com (Oli Sennhauser) — Mon, 01 Jan 0001 00:00:00 +0000

Jörg Brühe on FromDual GmbH

I blog di FromDual

Blog dei dipendenti FromDual

Aggregati di blog FromDual

Qual è il modo più veloce per caricare dati nel database?

Variante 1: INSERT e DELETE (forma più semplice)

Variante 2: START TRANSACTION e INSERT e DELETE

Variante 3: START TRANSACTION e INSERT e DELETE ottimizzati

Configurazione del test

Preparazione ed esecuzione con MariaDB/MySQL

Preparazione ed esecuzione con PostgreSQL

Risultati

Osservazioni

Altri contributi

MariaDB ha compromesso il concetto di buffer pool configurabile dinamicamente!

Descrizione del problema

Come funzionava prima?

Cosa fa MariaDB oggi?

Come funziona PostgreSQL?

Commenti

Quanto spazio occupa NULL?

Prova con MariaDB/MySQL

Configurazione di prova

Deframmentazione della tabella

Prova 1: riempire con NULL

Prova 2: cancellazione delle colonne

Conclusione

Prova con PostgreSQL

Configurazione della prova

Tentativo 1: riempire con NULL

Tentativo 2: cancellazione delle colonne

Osservazioni

Fonti

Prove aggiuntive

Qualcuno sta cancellando i miei segmenti di memoria condivisa!

Utente di sistema Linux

Variante semplice: modifica di SYS_UID_MAX e SYS_GID_MAX a 1001

Variante più complessa: modifica dell’UID da 1001 a 990

Informazioni aggiuntive

Caricare file CSV nel database

Caricamento dei dati con MariaDB/MySQL

Differenze tra MariaDB e MySQL

Fonti

Caricamento dei dati con PostgreSQL

Fonti

Piccole differenze tra MariaDB/MySQL e PostgreSQL

Osservazioni

Aggiunta

FromDual

Servizi per MariaDB, Galera e MySQL

Corsi di formazione MariaDB, Galera e MySQL in programma

Notizie FromDual

Test

Contattare FromDual

InnoDB deadlock con SELECT? Non è possibile! O forse sì?

Introduzione

Il problema

Modo per risolvere

La soluzione

Ulteriori domande chiarificatrici

Addendum

Ops! Pagina non trovata.

Variante 1: `INSERT` e `DELETE` (forma più semplice)

Variante 2: `START TRANSACTION` e `INSERT` e `DELETE`

Variante 3: `START TRANSACTION` e `INSERT` e `DELETE` ottimizzati

Prova 1: riempire con `NULL`

Tentativo 1: riempire con `NULL`

Variante semplice: modifica di `SYS_UID_MAX` e `SYS_GID_MAX` a 1001

Variante più complessa: modifica dell’`UID` da 1001 a 990