# Polars 2.0: hvorfor joins ikke lenger beholder radrekkefølgen sin

Published: 2026-10-08

Polars 2.0 kjører collect på en strømmemotor som standard. For join, group\_by og unpivot garanterer ikke lenger utgivelsen inputradrekkefølge med mindre du eksplisitt angir maintain\_order eller sort. I vår kjøring på Polars 2.0.0 returnerte en indre join med 2 000 000 rader rader ut av inputrekkefølge som standard og beholdt rekkefølgen med maintain\_order satt. Utgivelsen slår også på "out-of-core spilling" og gjør benchmark-påstandene til leverandørens egne.

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

## Hva denne videoen dekker

- Kall av collect() på en "lazy query" bruker nå strømmemotoren som standard, som ikke garanterer radrekkefølge for join, group\_by og unpivot.
- Migrasjonsguiden sier at rekkefølgen ikke lenger er rekkefølgen før 2.0 og er ikke garantert; den anbefaler en eksplisitt sortering hvis du er avhengig av det.
- I vår kjøring returnerte en standard indre join inputrekkefølge False; maintain\_order="left\_right" på join returnerte True. Én maskin, én kjøring, én join-form.
- Out-of-core spilling er på som standard: den starter på omtrent 80 % av RAM, med et standard diskbudsjett på 64 GB. Out-of-core join og group\_by er på veikartet.
- collect\_schema() fanger en manglende kolonne før noen data leses, men en "cast" som mislykkes på bare én verdi, mislykkes først ved collect().
- TPC-H- og TPC-DS-sammenligningen er leverandørens egen kjøring på avledede data, og fotnoten sier at resultatene ikke kan sammenlignes med offisielle benchmarks.

## Kapitler

- 0:00 Hvorfor endret standardrekkefølgen seg?
- 0:56 Hva lover migrasjonsguiden?
- 1:17 Er benchmarken en rettferdig kamp?
- 1:41 Hva ser vi når vi kjører den?
- 1:56 Betyr strengere tidligere?
- 2:07 Hvordan får jeg tilbake den gamle rekkefølgen?
- 2:20 Hva er dommen?

## Oversatt transkripsjon

Oversatt fra den originale engelske fortellingen. Tilgjengelig lyd og undertekster kontrolleres av YouTube.

### Hvorfor endret standardrekkefølgen seg?

0:00 Du tror en join gir deg radene tilbake i den rekkefølgen du skrev dem. Polars 2.0 sluttet å love det, som standard, med vilje. I denne videoen: hvorfor endret standarden seg? Hva kjøpte den? Og hvilket av skriptene dine ryker først? Dette er The Daily Diff, under panseret. Polars er et åpen kildekode DataFrame-bibliotek: en tabellmotor du kaller fra Python,

0:20 med kjernen skrevet i Rust. Det er gratis under MIT-lisensen, og du installerer det med pip install polars. Én detalj først. Bryteren som bringer den gamle rekkefølgen tilbake er et argument til selve joinen. Jeg kommer tilbake til det på slutten. Siden 2.0 kjører collect strømmemotoren som standard. Strømming deler spørringen i biter som kjører parallelt, og bitene fullføres når de fullføres.

0:42 For join, group by og unpivot lover ikke utgivelsen en rekkefølge. Hvem blir rammet først? Den som sammenligner utdata med en lagret fil, rad for rad. Den testen kan bestå på din laptop og feile på en annen maskin. Deretter migrasjonsguiden.

### Hva lover migrasjonsguiden?

0:57 Den sier at den eksakte radrekkefølgen vist ovenfor ikke er garantert. Så hvis du er avhengig av rekkefølgen, sorter eksplisitt. Out-of-core er også på som standard. Den begynner å "spille" til disk ved omtrent åtti prosent av RAM, med et sekstifire gigabyte budsjett. Sort, vindusfunksjoner og mange uttrykk kan "spill" nå. Joins og group-bys kommer.

### Er benchmarken en rettferdig kamp?

1:17 Polars sier det slår DataFusion og DuckDB på TPC-H og TPC-DS benchmarks. Tallene kommer fra deres egne kjøringer, på avledede data, og fotnoten deres sier at de ikke kan sammenlignes med offisielle resultater. Deres egne tall sier at Polars blir omtrent tre komma åtte ganger raskere fra seksten kjerner til et hundre nittito, på TPC-H. De sier også at den store maskinens ekstra tråder bremser små spørringer.

### Hva ser vi når vi kjører den?

1:41 Vi kjørte den samme join to ganger på Polars 2.0.0. Standard kjøring stokker om radene. Med flagget overlever inputrekkefølgen. Finn joins som mater en test. Enhver join uten en sortering etterpå er en radrekkefølgebeslutning du aldri tok. Polars 2.0 er strengere med typer.

### Betyr strengere tidligere?

1:58 Skjemakontrollen fanger en manglende kolonne før noen data leses. Den kan ikke fange en "cast" som mislykkes på én rad, fordi den feilen venter på dataene. Nå loopen jeg åpnet.

### Hvordan får jeg tilbake den gamle rekkefølgen?

2:08 Bryteren sitter på joinen. Sett "maintain order" på joinen, eller legg til en sortering etterpå. Guiden foreslår sorteringen. Join-flagget beholdt rekkefølgen i vår kjøring, med venstre sides rekkefølge beholdt som venstre, høyre. Dom, under panseret: NEEDS REVIEW.

### Hva er dommen?

2:22 Jeg ville gjennomgått hver join før oppgradering. Har du et spørsmål om dette? Legg det i kommentarene. Og det er The Daily Diff for i dag. Jeg er Niko fra Axrisi. Flett ansvarlig.

## Kilder

- [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