# Polars 2.0: perché i join non mantengono più l'ordine delle righe

Published: 2026-10-08

Polars 2.0 esegue collect su un motore di streaming per impostazione predefinita. Per join, group\_by e unpivot, la release non garantisce più l'ordine delle righe di input a meno che non si imposti esplicitamente maintain\_order o sort. Nella nostra esecuzione su polars 2.0.0, un inner join di 2.000.000 di righe ha restituito le righe in ordine diverso da quello di input per impostazione predefinita e ha mantenuto l'ordine con maintain\_order impostato. La release abilita anche lo spilling out-of-core e rende le affermazioni sui benchmark proprie del fornitore.

Canonical: https://thedailydiff.dev/it/video/polars-2-row-order/

## Contenuto di questo video

- La chiamata a collect() su una query lazy ora utilizza il motore di streaming per impostazione predefinita, che non garantisce l'ordine delle righe per join, group\_by e unpivot.
- La guida alla migrazione afferma che l'ordine non è più quello pre-2.0 e non è garantito; raccomanda un ordinamento esplicito se ci si basa su di esso.
- Nella nostra esecuzione, un inner join predefinito ha restituito l'ordine di input come False; maintain\_order="left\_right" sul join ha restituito True. Una macchina, una esecuzione, una forma di join.
- Lo spilling out-of-core è attivo per impostazione predefinita: inizia a circa l'80% della RAM, con un budget predefinito su disco di 64 GB. I join e group\_by out-of-core sono sulla roadmap.
- collect\_schema() rileva una colonna mancante prima che vengano letti i dati, ma un cast che fallisce su un solo valore fallisce solo a collect().
- Il confronto TPC-H e TPC-DS è l'esecuzione propria del fornitore su dati derivati, e la sua nota a piè di pagina afferma che i risultati non sono comparabili ai benchmark ufficiali.

## Capitoli

- 0:00 Perché è cambiato l'ordine predefinito?
- 0:56 Cosa promette la guida alla migrazione?
- 1:17 Il benchmark è uno scontro equo?
- 1:41 Cosa vediamo quando lo eseguiamo?
- 1:56 Più rigoroso significa prima?
- 2:07 Come ripristino il vecchio ordine?
- 2:20 Qual è il verdetto?

## Trascrizione tradotta

Tradotto dalla narrazione originale inglese. L'audio e i sottotitoli disponibili sono controllati da YouTube.

### Perché è cambiato l'ordine predefinito?

0:00 Pensate che un join vi restituisca le righe nell'ordine in cui le avete scritte. Polars 2.0 ha smesso di prometterlo, per impostazione predefinita, di proposito. In questo video: perché è cambiato il valore predefinito? Cosa ha ottenuto? E quale dei vostri script si romperà per primo? Questo è The Daily Diff, sotto il cofano. Polars è una libreria DataFrame open-source: un motore di tabelle che si chiama da Python,

0:20 con il suo core scritto in Rust. È gratuito sotto licenza MIT e si installa con pip install polars. Un dettaglio prima. L'interruttore che ripristina il vecchio ordine è un argomento del join stesso. Ci tornerò alla fine. Dal 2.0, collect esegue il motore di streaming per impostazione predefinita. Lo streaming divide la query in chunk che vengono eseguiti in parallelo, e i chunk finiscono quando finiscono.

0:42 Per join, group by e unpivot, la release non promette un ordine. Chi viene colpito per primo? Chiunque confronti l'output con un file salvato, riga per riga. Quel test può passare sul vostro laptop e fallire su una macchina diversa. Successivamente, la guida alla migrazione.

### Cosa promette la guida alla migrazione?

0:57 Dice che l'esatto ordine delle righe mostrato sopra non è garantito. Quindi, se vi affidate all'ordine, ordinate esplicitamente. Anche l'out-of-core è attivo per impostazione predefinita. Inizia a riversare su disco a circa l'ottanta percento della RAM, con un budget di sessantaquattro gigabyte. Sort, funzioni finestra e molte espressioni possono riversarsi ora. I join e i group-by stanno arrivando.

### Il benchmark è uno scontro equo?

1:17 Polars afferma di battere DataFusion e DuckDB nei benchmark TPC-H e TPC-DS. I numeri provengono dalle loro stesse esecuzioni, su dati derivati, e la loro nota a piè di pagina dice che non sono comparabili ai risultati ufficiali. I loro stessi numeri dicono che Polars diventa circa tre virgola otto volte più veloce da sedici core a centonovantadue, su TPC-H. Dicono anche che i thread extra della macchina grande rallentano le query piccole.

### Cosa vediamo quando lo eseguiamo?

1:41 Abbiamo eseguito lo stesso join due volte su Polars 2.0.0. L'esecuzione predefinita rimescola le righe. Con il flag, l'ordine di input sopravvive. Trovate i join che alimentano un test. Qualsiasi join senza un ordinamento dopo di esso è una decisione sull'ordine delle righe che non avete mai preso. Polars 2.0 è più rigoroso sui tipi.

### Più rigoroso significa prima?

1:58 Il controllo dello schema rileva una colonna mancante prima che vengano letti i dati. Non può rilevare un cast che fallisce su una riga, perché quell'errore attende i dati. Ora il ciclo che ho aperto.

### Come ripristino il vecchio ordine?

2:08 L'interruttore si trova sul join. Impostate maintain\_order sul join, o aggiungete un ordinamento dopo di esso. La guida suggerisce l'ordinamento. Il flag del join ha mantenuto l'ordine nella nostra esecuzione, con l'ordine del lato sinistro mantenuto come sinistra, destra. Verdetto, sotto il cofano: NEEDS REVIEW.

### Qual è il verdetto?

2:22 Revisionerei ogni join prima di effettuare l'aggiornamento. Avete domande su questo? Mettetele nei commenti. E questo è il diff per oggi. Sono Niko di Axrisi. Effettuate il merge in modo responsabile.

## Fonti

- [Release of Polars 2.0](https://pola.rs/posts/release-polars-2/) — Polars (pola.rs)
- [Polars 2.0 upgrade guide](https://docs.pola.rs/releases/upgrade/2/) — Polars documentation
- [Polars homepage](https://pola.rs/) — Polars (pola.rs)
- [polars-2.0-benchmark repository](https://github.com/pola-rs/polars-2.0-benchmark) — Polars on GitHub
- [Release of Polars 2.0 (Hacker News discussion)](https://news.ycombinator.com/item?id=49977177) — Hacker News