Spcnet.it

2026-04-23 15:01:47

Addio byte[]: allocazioni a costo zero in .NET Framework con ReadOnlySpan

Uno dei pattern di ottimizzazione più semplici e meno conosciuti nel mondo .NET è la sostituzione dei campi static readonly byte[] con proprietà static ReadOnlySpan<byte>. Andrew Lock, noto per le sue analisi approfondite su ASP.NET Core e il runtime, ha pubblicato un articolo che conferma un dettaglio fondamentale: questa tecnica funziona anche su .NET Framework, basta il pacchetto NuGet System.Memory. Zero allocazioni, zero costo di startup, nessuna pressione sul garbage collector.

Il problema: allocazioni “gratuite” che non lo sono

Consideriamo un pattern che troviamo in quasi tutte le librerie che manipolano dati binari: signature di file, magic number, header fissi, tabelle di lookup. Tipicamente si scrive:

public static class MyStaticData
{
    private static readonly byte[] ByteField = new byte[] { 1, 2, 3, 4 };
}

Sembra innocuo: un singolo array, allocato una volta sola al caricamento del tipo. Ma in un processo con migliaia di tipi simili — pensiamo a un parser di formati immagine, a una libreria di crittografia, a un framework web — queste allocazioni si sommano. Ogni array è un oggetto gestito: richiede header, richiede tracciamento GC, occupa spazio sulla Gen 2 (perché sopravvive per sempre) e aumenta i tempi di startup.

La soluzione: ReadOnlySpan<byte> come proprietà

La trasformazione è quasi meccanica:

public static class MyStaticData
{
    private static ReadOnlySpan<byte> ReadOnlySpanProp => new byte[] { 1, 2, 3, 4 };
}

Sintatticamente sembra che stiamo allocando un array ogni volta che accediamo alla proprietà. In realtà è esattamente il contrario: il compilatore C# riconosce questo pattern e incorpora i byte direttamente nei metadati dell’assembly, costruendo lo span con un puntatore a quei dati. Non viene mai eseguito newarr.

L’IL generato mostra chiaramente la magia:

IL_0000: ldsflda      int32 '<PrivateImplementationDetails>'::'...'
IL_0005: ldc.i4.4
IL_0006: newobj       instance void valuetype [System.Memory]System.ReadOnlySpan`1<unsigned int8>::.ctor(void*, int32)
IL_000b: ret

I dati vivono in una sezione di sola lettura dell’assembly; lo span viene costruito on-the-fly con pointer + length. È essenzialmente gratuito.

Letterali UTF-8: lo stesso trucco, più ergonomico

A partire da C# 11 (.NET 7), la stessa ottimizzazione si ottiene con i letterali UTF-8:

private static ReadOnlySpan<byte> Utf8Hello => "Hello world"u8;

Il suffisso u8 istruisce il compilatore a codificare la stringa direttamente in UTF-8 nell’assembly. Molto utile per header HTTP, prefissi di protocollo, marker di formato binari — tutti casi in cui storicamente si manteneva una byte[] statica generata da Encoding.UTF8.GetBytes.

I vincoli da rispettare

L’ottimizzazione non si applica in modo uniforme. Vale solo per i tipi a byte singolo:

• byte[]
• sbyte[]
• bool[]

Per gli altri tipi primitivi (int, long, double…) entra in gioco l’endianness: su .NET 7 e successivi c’è RuntimeHelpers.CreateSpan<T>() che la gestisce in modo trasparente, ma su .NET Framework il compilatore emette codice che cache l’array in un campo statico alla prima chiamata. Ancora efficiente, ma non zero-alloc.

Il secondo vincolo è che tutti i valori devono essere costanti a compile-time:

// Anti-pattern: alloca a ogni accesso
private static readonly byte One = 1;
private static ReadOnlySpan<byte> Bad => new byte[] { One, 2, 3, 4 };

Qui One è un campo, non una costante, quindi il compilatore deve costruire l’array a runtime. La differenza tra const byte e static readonly byte diventa improvvisamente importante.

Il terzo vincolo è usare ReadOnlySpan<T>, mai Span<T>:

// Sbagliato: alloca un array mutabile a ogni accesso
private static Span<byte> MutSpan => new byte[] { 1, 2, 3, 4 };

Uno Span<byte> potrebbe essere scritto, e modificare dati immutabili condivisi sarebbe catastrofico. Il compilatore quindi non applica l’ottimizzazione.

Il supporto su .NET Framework

Questa è la parte più interessante: il trucco funziona su .NET Framework 4.6.2+ semplicemente referenziando il pacchetto System.Memory:

<ItemGroup>
  <PackageReference Include="System.Memory" Version="4.6.3" />
</ItemGroup>

La ragione è che l’ottimizzazione è una feature del compilatore, non del runtime: serve solo che ReadOnlySpan<T> esista come tipo, e il pacchetto System.Memory lo fornisce. Chi mantiene librerie multi-target può quindi applicare questa ottimizzazione senza creare codice condizionale #if NET6_0_OR_GREATER.

Collection expressions: la rete di sicurezza

Su C# 12 e successivi le collection expressions offrono protezione a compile-time:

// Compila e non alloca
private static ReadOnlySpan<byte> Safe => [1, 2, 3, 4];

// Errore CS9203 — il compilatore rifiuta
private static Span<byte> Dangerous => [1, 2, 3, 4];

L’errore CS9203 è un salvavita: impedisce di assegnare una collection expression a un tipo Span<T> in contesti static, perché il risultato sarebbe condivisibile e mutabile. Su .NET Framework o su versioni di C# precedenti questa protezione non esiste, quindi serve attenzione in fase di code review.

Quando applicarla nel codice reale

Le candidate ideali sono costanti binarie che vivono in campi static readonly byte[]: magic number (PNG, ZIP, PDF), prefissi protocollari, tabelle di sostituzione, chiavi di test fisse, certificati embedded. Il refactoring è meccanico e non cambia l’API pubblica della classe se la visibility è private.

Attenzione invece ai metodi che accettano byte[]: non possiamo passare uno ReadOnlySpan<byte> a un’API che richiede un array. In questi casi la scelta è tra riscrivere il consumer per accettare ReadOnlySpan<byte> (preferibile) o mantenere l’array tradizionale. Molte API del BCL sono già state aggiornate negli ultimi anni: Stream.Write, HashAlgorithm.ComputeHash, Encoding.GetString accettano tutti ReadOnlySpan<byte> in overload moderni.

Conclusione

Cambiare static readonly byte[] in static ReadOnlySpan<byte> => è uno di quei refactoring che riducono allocazioni e startup con una modifica locale a costo zero. Funziona anche su .NET Framework, quindi vale la pena considerarla durante la manutenzione di codice legacy — un punto che spesso sfugge perché l’ecosistema associa Span<T> esclusivamente a .NET moderno.

Fonte: Removing byte[] allocations in .NET Framework using ReadOnlySpan<T> di Andrew Lock.

Removing byte[] allocations in .NET Framework using ReadOnlySpan

In this post I describe how to remove static byte[] allocations, even on .NET Framework, by using Span, look at the associated IL, and discuss the risks

^{Andrew Lock (Andrew Lock | .NET Escapades)}

(in)sicurezza digitale

2026-04-23 12:32:05

Checkmarx nel mirino di TeamPCP: l’immagine Docker ufficiale di KICS trojanizzata per esfiltrare i segreti dell’infrastruttura

Si parla di:
Toggle

Il 22 aprile 2026 Docker, Inc. ha rilevato attività sospette sul repository ufficiale checkmarx/kics e ha allertato i ricercatori di Socket. L’analisi ha confermato il peggiore degli scenari per un vendor di security scanner: le immagini Docker ufficiali dello strumento open source KICS (Keeping Infrastructure as Code Secure) erano state sostituite con versioni trojanizzate, progettate per generare, cifrare ed esfiltrare i report di scansione completi insieme a token cloud, credenziali GitHub e chiavi SSH di ogni pipeline CI/CD che le eseguiva. Poche ore dopo, l’account @pcpcats rivendicava l’operazione: «Thank you OSS distribution for another very successful day at PCP inc.»

Non è la prima volta che Checkmarx finisce nel mirino di TeamPCP. A marzo 2026 lo stesso gruppo aveva compromesso due workflow GitHub Actions di Checkmarx e plugin distribuiti tramite OpenVSX, colpendo nella stessa ondata anche Trivy e LiteLLM. L’attacco di aprile rappresenta però un salto qualitativo: non si limita più al codice sorgente o agli action, ma colpisce direttamente i binary artifact distribuiti ufficialmente dal vendor, trasformando uno strumento che gli ingegneri installano proprio per cercare vulnerabilità in un vettore di furto di segreti su scala globale.

Che cos’è KICS e perché è un bersaglio ideale

KICS è uno scanner open source per Infrastructure-as-Code mantenuto da Checkmarx, ampiamente integrato nelle pipeline CI/CD per rilevare misconfiguration in Terraform, CloudFormation, Ansible, Kubernetes manifests e Dockerfile. Per sua stessa natura, viene eseguito con accesso di lettura all’intero repository, ai file di configurazione, ai secret dell’ambiente di build e spesso alle credenziali cloud a breve durata emesse dal provider di CI. Compromettere KICS significa ottenere, per ogni installazione infetta, una vista privilegiata sui crown jewels della pipeline.

Il vettore Docker Hub: tag sovrascritti e un v2.1.21 fantasma

Gli attaccanti hanno sovrascritto tag esistenti del repository checkmarx/kics — tra cui alpine, latest, debian, v2.1.20 e v2.1.20-debian — e hanno introdotto un tag v2.1.21 che non corrisponde ad alcun rilascio ufficiale del progetto. Questa tecnica è particolarmente insidiosa: ogni sistema che effettua docker pull checkmarx/kics:latest o che aggiorna l’immagine di base nei workflow di CI scarica silenziosamente la versione compromessa, senza allarmi da parte dei tool di dipendency scanning che si fidano del nome del repository ufficiale.

Il binario ELF di KICS all’interno dell’immagine è stato modificato per mantenere la funzionalità legittima (la scansione si completa senza errori, non ci sono segnali visibili di compromissione nei log) e aggiungere in parallelo una routine di raccolta dati che genera un report di scansione non censurato, lo cifra e lo invia a un endpoint esterno. In pratica, i file di configurazione che contengono password, token e connection string — normalmente redatti dai report pubblici di KICS — vengono esportati in chiaro verso l’infrastruttura dell’attaccante.

L’estensione VS Code e il payload mcpAddon.js

La campagna non si ferma alle immagini Docker. Socket ha identificato malware anche nelle estensioni Checkmarx per Visual Studio Code pubblicate sul marketplace Microsoft e su OpenVSX. Le versioni compromesse sono checkmarx.cx-dev-assist@1.17.0 e @1.19.0, oltre a checkmarx.ast-results@2.63.0 e @2.66.0 (la 1.18.0 risulta pulita, con il malware temporaneamente rimosso nel ciclo di release).

Il meccanismo è chirurgico: gli attaccanti hanno iniettato un commit retrodatato (68ed490b) nel repository Checkmarx/ast-vscode-extension contenente un file di circa 10 MB in modules/mcpAddon.js. Il modulo viene stageed per l’esecuzione runtime tramite l’interprete Bun, una scelta che riduce la probabilità di rilevazione rispetto all’esecuzione tradizionale in Node.js e permette di eseguire codice JavaScript con minore scrutinio da parte degli EDR endpoint.

Cosa ruba realmente mcpAddon.js

Il payload è un infostealer di caratura operativa avanzata. Esegue comandi nativi sulla macchina della vittima per raccogliere un dossier completo di credenziali:

• Token di autenticazione GitHub tramite gh auth token
• Credenziali AWS dai file di configurazione standard
• Token Azure tramite az account get-access-token e azd auth token
• Configurazioni Google Cloud tramite gcloud config config-helper
• Token npm dai file .npmrc dell’utente
• Chiavi SSH e file di configurazione
• File di configurazione di Claude Code e di altri MCP client
• Variabili d’ambiente selezionate del processo

L’inclusione esplicita dei file di configurazione MCP è un segnale che TeamPCP sta mappando non solo le supply chain tradizionali, ma anche l’ecosistema emergente degli agenti AI — che a loro volta conservano token per molteplici servizi di terze parti.

Esfiltrazione via repository GitHub pubblici: l’ingegno del «vocabolario Dune»

L’aspetto più creativo dell’operazione riguarda l’esfiltrazione. Invece di esfiltrare direttamente verso un C2 facilmente bloccabile, il malware crea repository GitHub pubblici con nomi casuali costruiti dal pattern <word>-<word>-<3 digits>, attingendo a un vocabolario ispirato all’universo di Dune — «gesserit», «melange», «fedaykin», «ornithopter», «atreides», «sandworm». Ogni repository ospita tre file: envelope con il payload cifrato, key con la chiave di decifratura (a sua volta cifrata), e token con un identificativo che lega il furto alla vittima.

I messaggi di commit incorporano token aggiuntivi secondo il pattern «LongLiveTheResistanceAgainstMachines:<encoded>», uno slogan ricorrente nel folklore di TeamPCP. Questa architettura rende la rilevazione molto più complessa: il traffico di esfiltrazione è indistinguibile dal normale uso di GitHub da parte di sviluppatori.

Il workflow format-check.yml e l’abuso di toJSON(secrets)

Nell’operazione di marzo, TeamPCP aveva già dimostrato padronanza dei GitHub Actions: il workflow maligno .github/workflows/format-check.yml sfruttava l’espressione ${{ toJSON(secrets) }} per serializzare tutti i segreti del repository e dell’organizzazione in un artefatto JSON scaricabile per 90 giorni. È una tecnica di supply chain attack elegante e sottovalutata, perché non richiede di esfiltrare alcunché verso infrastruttura esterna: GitHub stesso ospita il bottino, che diventa scaricabile con le sole credenziali dell’attaccante.

Propagazione npm via token rubati

Una volta ottenuti i token npm delle vittime, il malware cerca automaticamente pacchetti scrivibili interrogando l’endpoint /-/org/<user>/package e, in fallback, effettua ricerche con https://registry.npmjs.org/-/v1/search?text=maintainer:<user>&size=250. La logica è quella classica dei self-replicating npm worm già osservati in campagne come Shai-Hulud: ogni sviluppatore colpito diventa un potenziale vettore per nuove pubblicazioni malevoli.

Indicatori di Compromissione

== Hash ==
mcpAddon.js
  SHA256  24680027afadea90c7c713821e214b15cb6c922e67ac01109fb1edb3ee4741d9
  SHA1    2b12cc5cc91ec483048abcbd6d523cdc9ebae3f3
  MD5     d47de3772f2d61a043e7047431ef4cf4

kics (ELF binary trojanizzato)
  SHA256  2a6a35f06118ff7d61bfd36a5788557b695095e7c9a609b4a01956883f146f50
  SHA1    250f3633529457477a9f8fd3db3472e94383606a
  MD5     e1023db24a29ab0229d99764e2c8deba

== Docker tag compromessi (checkmarx/kics) ==
alpine, latest, debian, v2.1.20, v2.1.20-debian, v2.1.21 (fake)

== Index manifest digest ==
sha256:2588a44890263a8185bd5d9fadb6bc9220b60245dbcbc4da35e1b62a6f8c230d  (alpine/v2.1.20/v2.1.21)
sha256:222e6bfed0f3bb1937bf5e719a2342871ccd683ff1c0cb967c8e31ea58beaf7b  (debian variants)
sha256:a0d9366f6f0166dcbf92fcdc98e1a03d2e6210e8d7e8573f74d50849130651a0  (latest)

== Estensioni VS Code / OpenVSX ==
checkmarx.cx-dev-assist  1.17.0, 1.19.0   (malevole)
checkmarx.ast-results    2.63.0, 2.66.0   (malevole)

== C2 ==
audit.checkmarx[.]cx/v1/telemetry
94[.]154[.]172[.]43

== Pattern repository di staging ==
<word>-<word>-<3 digits> (vocabolario Dune: gesserit, melange, fedaykin,
ornithopter, atreides, sandworm, ...) con file envelope/key/token

== Pattern commit message ==
LongLiveTheResistanceAgainstMachines:<encoded>

Implicazioni e raccomandazioni

Il caso Checkmarx/KICS è un promemoria brutale: gli strumenti di security scanner sono essi stessi componenti della supply chain, spesso eseguiti con privilegi elevati dentro le pipeline più sensibili dell’organizzazione. Per chi gestisce ambienti che integrano KICS o altri scanner Checkmarx:

• Verificare le versioni pullate di checkmarx/kics negli ultimi 30 giorni e confrontare i digest con quelli pubblicati ufficialmente dal vendor dopo la rimediation.
• Effettuare il pin delle immagini Docker a digest SHA invece che a tag mutabili come latest o alpine.
• Controllare i log GitHub per workflow artefacts di dimensione anomala, in particolare quelli generati da workflow che referenziano toJSON(secrets).
• Ruotare tutti i token GitHub, npm, AWS, Azure e GCP che potrebbero essere stati esposti a sviluppatori con cx-dev-assist o ast-results nelle versioni compromesse.
• Monitorare la creazione di repository GitHub pubblici corrispondenti al pattern Dune descritto sopra.
• Bloccare o allertare sulle connessioni verso audit.checkmarx.cx (dominio di lookalike non legittimo di Checkmarx).

Il doppio colpo di TeamPCP a Checkmarx in meno di due mesi suggerisce che il gruppo conserva un accesso persistente o ricorrente agli ambienti di build del vendor, o quantomeno che alcune delle credenziali rubate nella prima ondata non sono state completamente invalidate. La security community attende risposte più dettagliate dal vendor su come il tag Docker ufficiale sia stato sovrascritto e su quale catena di fiducia debba essere ricostruita per i clienti che hanno integrato KICS nelle proprie pipeline negli ultimi mesi.

Spcnet.it

2026-04-23 07:54:20

TypeScript 7.0 Beta: il nuovo compilatore in Go è circa 10 volte più veloce

Il team di TypeScript ha rilasciato la beta ufficiale di TypeScript 7.0, e non si tratta di un aggiornamento incrementale: il compilatore è stato riscritto in Go, con miglioramenti di performance che in molti scenari superano un fattore 10x. Dopo quasi un anno di anteprime tecniche sotto il nome TypeScript Native Preview, Microsoft porta la versione nativa del compilatore a un pubblico molto più ampio e la raccomanda per uso quotidiano, pur restando formalmente in beta.

Perché riscrivere il compilatore in Go

Il compilatore di TypeScript era storicamente scritto nello stesso linguaggio che compilava. Questa scelta, elegante dal punto di vista del bootstrapping, ha sempre comportato un costo: su codebase di grandi dimensioni il tsc può impiegare decine di secondi (o minuti) per il type-checking e il watch mode si appesantisce rapidamente all’aumentare dei file.

La riscrittura in Go non è un rewrite da zero: il team parla esplicitamente di un port metodico, mantenendo parità strutturale con la logica di type-checking di TypeScript 6.0. Questo approccio riduce il rischio di regressioni semantiche: la stessa base di casi di test, le stesse regole, ma con le velocità permesse da codice nativo e dal parallelismo reale a memoria condivisa.

Il risultato, secondo Microsoft, è che TypeScript 7.0 è circa 10 volte più veloce di TypeScript 6.0. Team come Bloomberg, Figma, Google, Slack e Vercel hanno riportato numeri comparabili durante la beta privata, con riduzioni drastiche dei tempi di build in CI.

Come provarlo oggi

L’installazione avviene come package separato per non rompere le pipeline esistenti. Basta un singolo comando:

npm install -D @typescript/native-preview@beta
npx tsgo --version
# Version 7.0.0-beta

Durante la fase beta, l’eseguibile si chiama tsgo al posto di tsc. Per Visual Studio Code è disponibile l’estensione “TypeScript Native Preview”, che affianca il language service classico permettendo di confrontare i tempi di risposta in tempo reale.

Parallelismo configurabile

Una delle novità più sottili, ma con maggiore impatto pratico, è il parallelismo integrato nel compilatore:

• --checkers N: numero di worker dedicati al type-checking (default 4). I worker mantengono viste indipendenti per evitare ricalcoli ridondanti, ma i risultati restano deterministici.
• --builders N: abilita la compilazione parallela di più progetti referenziati (project references). Ha un effetto moltiplicativo quando combinato con --checkers, ed è particolarmente efficace nei monorepo.
• --singleThreaded: forza l’esecuzione sequenziale per debugging o ambienti con memoria limitata (container CI con poca RAM, ad esempio).

Alzare --checkers aumenta la velocità ma anche il consumo di memoria: su agenti CI piccoli conviene fare qualche prova empirica prima di spingerlo oltre 8.

Breaking changes: la pulizia annunciata

TypeScript 7.0 è anche l’occasione per rimuovere anni di retrocompatibilità. Chi mantiene progetti legacy dovrà prestare attenzione, perché molte opzioni di configurazione sono semplicemente scomparse:

• target: es5 non è più supportato.
• downlevelIteration, moduleResolution: node/node10/classic, e i moduli amd, umd, systemjs, none sono stati rimossi.
• baseUrl è stato eliminato: usare paths relativo alla root del progetto.
• esModuleInterop, allowSyntheticDefaultImports e alwaysStrict non possono più essere disattivati.

Cambiano anche diversi default: strict: true, module: esnext, target pari all’ultima versione ECMAScript stabile prima di esnext, noUncheckedSideEffectImports: true, e soprattutto types: []. Quest’ultimo è il cambiamento che più spesso romperà le build: prima @types/* venivano inclusi automaticamente, ora vanno dichiarati esplicitamente:

{
  "compilerOptions": {
    "types": ["node", "jest"]
  }
}

Sul fronte del supporto a JavaScript con JSDoc, la pulizia è ancora più netta: i valori non possono più sostituire i tipi (usare typeof valore), la sintassi Closure-style function(string): void è rimossa, così come @enum e l’operatore postfisso !.

Convivenza con TypeScript 6.0

Per chi non può migrare subito tutte le pipeline, è possibile installare entrambe le versioni affiancate:

npm install -D typescript@npm:@typescript/typescript6

Così typescript continua a puntare a 6.0, mentre tsgo (o tsc7 dopo il rilascio finale) resta disponibile come entry point separato. È lo scenario consigliato per confrontare gradualmente i due compilatori su progetti reali prima di fare il cutover.

Roadmap e cosa aspettarsi

La beta è datata 21 aprile 2026; il rilascio stabile è previsto entro due mesi, con una release candidate alcune settimane prima. Nel frattempo arriveranno un --watch più efficiente, la parità di declaration file emit per JavaScript, miglioramenti all’editor (ricerca dei riferimenti ai file, comandi import/export più granulari) e una API programmatica stabile, attesa per TypeScript 7.1 o successiva.

Vale la pena migrare subito?

Per team che lavorano su codebase grandi e soffrono di type-check lenti, la risposta è “quasi sicuramente sì, almeno in parallelo”. Microsoft stessa dichiara il compilatore “altamente stabile e altamente compatibile” sulla base di test su codebase da milioni di righe. La strategia più prudente è: installare @typescript/native-preview come dev dependency aggiuntiva, introdurlo come job di CI opzionale accanto al tsc esistente, misurare i tempi reali e segnalare eventuali incompatibilità sul repository microsoft/typescript-go.

Le incompatibilità che emergeranno non saranno di natura logica ma di configurazione: soprattutto il nuovo default types: [] e la rimozione di baseUrl. Chi si è tenuto aggiornato con le versioni recenti dovrebbe cavarsela con poche modifiche al tsconfig.json.

Fonte: Announcing TypeScript 7.0 Beta di Daniel Rosenwasser sul blog ufficiale TypeScript (Microsoft DevBlogs).

Announcing TypeScript 7.0 Beta - TypeScript

Today we are absolutely thrilled to announce the release of TypeScript 7.0 Beta! If you haven’t been following TypeScript 7.0’s development, this release is significant in that it is built on a completely new foundation.

^{Daniel Rosenwasser (TypeScript)}

Spcnet.it

2026-04-22 15:21:43

12 tecniche per ottimizzare le query PostgreSQL su dataset di grandi dimensioni

Quando una tabella PostgreSQL cresce oltre il milione di righe, query che prima restituivano risultati in millisecondi iniziano ad impiegare secondi — o peggio. La buona notizia è che PostgreSQL offre strumenti potenti per affrontare questo problema. La cattiva notizia è che molti sviluppatori conoscono solo una parte di questi strumenti.

In questo articolo passiamo in rassegna le 12 tecniche più efficaci per ottimizzare le query su grandi dataset, con esempi SQL concreti per ciascuna.

1. Creare indici sulle colonne frequentemente filtrate

Il consiglio più noto, ma non per questo meno importante. Un indice trasforma una scansione sequenziale (O(n)) in una ricerca B-tree (O(log n)). La differenza su una tabella da un milione di righe può essere di due ordini di grandezza.

-- Prima: full sequential scan su ordini
SELECT * FROM orders WHERE customer_id = 42;

-- Creazione dell'indice
CREATE INDEX idx_orders_customer_id ON orders(customer_id);

-- Dopo: index scan, da 240ms a pochi ms

Usate EXPLAIN ANALYZE per verificare che l’indice venga effettivamente utilizzato.

2. Normalizzare il database in modo strategico

La normalizzazione riduce la ridondanza e migliora la coerenza dei dati, ma va applicata con giudizio. Una normalizzazione eccessiva crea decine di JOIN che possono diventare colli di bottiglia. La regola pratica: normalizzate i dati che cambiano spesso o che hanno alta cardinalità (liste di prodotti, clienti, categorie), denormalizzate i dati storici o di report dove la velocità di lettura è critica.

3. Evitare SELECT *

Selezionare tutte le colonne ha due costi nascosti: aumenta il volume di I/O e impedisce a PostgreSQL di soddisfare la query direttamente dall’indice (index-only scan). Specificate sempre le colonne necessarie:

-- Evitare
SELECT * FROM orders WHERE customer_id = 42;

-- Preferire
SELECT id, created_at, total_amount FROM orders WHERE customer_id = 42;

Quando le colonne selezionate fanno parte di un indice composito, PostgreSQL può restituire i dati senza accedere all’heap, eliminando un intero livello di I/O.

4. Ordinare i JOIN in modo efficiente

Il query planner moderno di PostgreSQL determina autonomamente l’ordine ottimale dei JOIN grazie al cost-based optimizer. Tuttavia, in scenari con molte tabelle o con join_collapse_limit ridotto, conviene strutturare i JOIN in modo che le tabelle più piccole (o più filtrate) vengano processate per prime, riducendo la cardinalità delle operazioni successive.

5. Usare LIMIT durante l’esplorazione dei dati

Apparentemente ovvio, ma spesso trascurato: se l’interfaccia utente mostra al massimo 50 risultati, non ha senso recuperarne un milione dal database.

SELECT id, name, email 
FROM customers 
ORDER BY created_at DESC 
LIMIT 50 OFFSET 0;

Attenzione al pagination problem: con OFFSET elevati, PostgreSQL scansiona comunque tutte le righe precedenti. Per paginazione su grandi dataset, preferite il keyset pagination (cursor-based).

6. Indici parziali per subset frequenti

Un indice parziale indicizza solo le righe che soddisfano una condizione, riducendo dimensioni e costo di manutenzione:

-- Indice solo sugli ordini completati (subset più frequentemente interrogato)
CREATE INDEX idx_completed_orders
ON orders(customer_id)
WHERE status = 'Completed';

-- La query deve includere la stessa condizione per usare l'indice
SELECT id, total_amount 
FROM orders 
WHERE customer_id = 42 AND status = 'Completed';

In un test pratico, questo indice ha dimezzato i tempi rispetto a un indice standard su tutte le righe.

7. Usare i tipi di dato più piccoli necessari

Ogni byte conta quando moltiplicato per milioni di righe. Preferite sempre il tipo più compatto che soddisfa il requisito:

• integer (4 byte) invece di bigint (8 byte) per chiavi primarie < 2 miliardi
• smallint (2 byte) per enumerazioni con pochi valori
• timestamp invece di timestamptz se il fuso orario è fisso
• varchar(n) con limite appropriato invece di text illimitato dove possibile

Tipi più piccoli significano pagine di dati più dense, quindi meno I/O per ogni query.

8. Non applicare funzioni sulle colonne indicizzate

Applicare una funzione a una colonna indicizzata invalida l’utilizzo dell’indice:

-- L'indice su name NON viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

-- Soluzione: creare un indice funzionale
CREATE INDEX idx_customers_lower_name ON customers(LOWER(name));

-- Ora l'indice viene usato
SELECT * FROM customers WHERE LOWER(name) = 'mario rossi';

Lo stesso vale per funzioni su date come DATE(created_at): usate range di timestamp o create l’indice sulla funzione.

9. Partizionare le tabelle molto grandi

Il partizionamento divide una tabella logica in sotto-tabelle fisiche, permettendo a PostgreSQL di escludere partizioni irrilevanti (partition pruning) durante le query:

-- Tabella partizionata per anno
CREATE TABLE orders_partitioned (
    id         serial NOT NULL,
    customer_id integer,
    created_at  timestamp NOT NULL,
    CONSTRAINT pk_orders PRIMARY KEY (id, created_at)
) PARTITION BY RANGE (created_at);

-- Creazione delle partizioni annuali
CREATE TABLE orders_2024 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2024-01-01') TO ('2025-01-01');

CREATE TABLE orders_2025 PARTITION OF orders_partitioned
    FOR VALUES FROM ('2025-01-01') TO ('2026-01-01');

Una query che filtra per anno legge solo la partizione corrispondente, ignorando completamente le altre.

10. Usare le transazioni per operazioni bulk

PostgreSQL esegue un commit (e quindi una scrittura sincrona su WAL) dopo ogni statement. Raggruppare più operazioni in un’unica transazione riduce drasticamente i costi di I/O:

-- Lento: un commit per ogni INSERT
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000

-- Veloce: un solo commit per tutto il batch
BEGIN;
INSERT INTO log_events VALUES (...);
INSERT INTO log_events VALUES (...);
-- ... x 10.000
COMMIT;

In test pratici, l’approccio con transazione singola completa lo stesso lavoro in meno della metà del tempo rispetto agli inserimenti individuali.

11. Evitare transazioni long-running

Il modello MVCC (Multi-Version Concurrency Control) di PostgreSQL mantiene versioni multiple delle righe per garantire la consistenza delle letture. Le transazioni long-running bloccano il processo di VACUUM dal rimuovere le versioni obsolete, causando table bloat: tabelle che crescono fisicamente anche quando i dati logici non aumentano.

Spezzettate le operazioni pesanti in batch più piccoli e monitorate le transazioni attive con:

SELECT pid, now() - pg_stat_activity.query_start AS duration, query, state
FROM pg_stat_activity
WHERE state != 'idle' AND query_start IS NOT NULL
ORDER BY duration DESC;

12. Gestire il bloat con VACUUM

Ogni UPDATE e DELETE lascia righe “morte” sul disco. VACUUM le recupera:

-- VACUUM standard: recupera spazio senza bloccare le letture
VACUUM orders;

-- VACUUM FULL: recupera tutto lo spazio ma blocca l'accesso alla tabella
-- Usare solo in finestre di manutenzione programmate
VACUUM FULL orders;

-- Verificare lo stato del bloat
SELECT relname, n_dead_tup, n_live_tup,
       round(n_dead_tup::numeric / NULLIF(n_live_tup + n_dead_tup, 0) * 100, 2) AS dead_pct
FROM pg_stat_user_tables
ORDER BY n_dead_tup DESC
LIMIT 20;

Per la maggior parte dei workload, autovacuum è sufficiente. Assicuratevi che sia abilitato e calibrate i threshold in base al volume di modifiche della vostra applicazione:

-- Verificare la configurazione autovacuum per una tabella specifica
SELECT reloptions FROM pg_class WHERE relname = 'orders';

Riepilogo operativo

Non tutte le tecniche si applicano a ogni scenario. Un approccio efficace inizia sempre dall’analisi con EXPLAIN (ANALYZE, BUFFERS) per identificare i reali colli di bottiglia, poi applica le ottimizzazioni in modo mirato. L’indice sbagliato o il partizionamento mal configurato possono peggiorare le prestazioni invece di migliorarle.

Il punto di partenza universale resta lo stesso: misurare prima, ottimizzare dopo.

---

Fonte: 12 practices for optimizing PostgreSQL queries for large datasets — elmah.io Blog

12 practices for optimizing PostgreSQL queries for large datasets

Boost PostgreSQL performance with 12 expert tips for large datasets from partitioning to partial indexes and avoiding bloat. Stay fast and scale.

^{Ali Hamza Ansari (elmah.io Blog - .NET Technical tutorials/guides and new features)}