Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Perf: limit pushdown — avoid materializing full partitions for LIMIT queries

Ouverte
#131 1 commentaire 1 réaction 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Personne n'a encore pris cette issue.

Évaluation

Difficulté
4/5
Temps estimé
3-5 jours
Accessibilité débutants
48/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
python
Domaine
data, performance

Piste de recherche

Start by reading PrunableStreamingTable::scan() and the path that carries the limit through PyArrowStreamPartition into the partition factory; the issue names no file or test. Check how projection is passed as a model, then determine how the factory can stop producing rows at the requested limit. Done means a query such as SELECT * FROM ds LIMIT 10 avoids materializing the full first matching partition.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

enhancement

Problem

The partition factory always materializes the full partition regardless of query:

df = pivot(ds.isel(block))  # always loads all 38.4M rows

For queries like SELECT * FROM ds LIMIT 100, DataFusion applies the limit after the factory produces its batch. The factory receives no signal to stop early.

Currently limit is passed from PrunableStreamingTable::scan() down to DataFusion's StreamingTable, which applies it at the execution-plan level — but only after the factory has already materialized the full partition.

Proposed fix

Pass an optional row limit into the factory (similar to projection pushdown). The scan() method can thread the limit through PyArrowStreamPartition so the factory can stop generating rows once the limit is reached.

def make_stream(projection, limit=None) -> pa.RecordBatchReader:
    rows_needed = limit or total_rows
    # only materialize up to rows_needed rows

Impact

For ARCO-ERA5, LIMIT 10 currently reads 38.4M rows from the first matching partition. With this fix it would read at most batch_size rows.

Parent: #126

Langage dominant
Python
Étoiles
142
Forks
19
Merge moyen
1 j 9 h
PR mergées (30 j)
9

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de xqlsystems/xarray-sql

Toutes les issues de xqlsystems/xarray-sql

Issues similaires

Plus d'issues Python

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.