[Feature] Point-delete fast path for primary key DELETE to skip the target table scan

Ouverte
#8,836 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Personne n'a encore pris cette issue.

Évaluation

Difficulté
5/5
Temps estimé
Plus d'une semaine
Accessibilité débutants
35/100
Type d'issue
Fonctionnalité
Clarté
Plutôt claire
Activité
Calme
Stack technique
java
Domaine
data-engineering, databases

Piste de recherche

Commencez par DeleteFromPaimonTableCommand et suivez le chemin DELETE existant d'upsert par clé primaire. Comparez les cas literal/IN et sous-requête décrits dans l'issue, y compris le comportement de fallback et la limite d'expansion côté driver. Le travail est considéré comme terminé lorsque les DELETE concernés évitent le scan de la table cible, que les autres conditions conservent leur comportement existant et que les tests de l'implémentation couvrent ces cas.

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

Description

Search before asking
  • I searched in the issues and found nothing similar.
Motivation

Currently DELETE FROM on a primary-key table always scans the target table to find matching rows, even when the condition is just primary keys, e.g.:

DELETE FROM t WHERE id IN (1, 2, 3);
DELETE FROM t WHERE id IN (SELECT id FROM keys_to_delete);

For these cases the matched keys are already fully described by the condition itself, so we can build the -D records directly and skip the target table scan entirely. On large tables (we have a case deleting ~10 million keys from a multi-billion-row table by a key table) this is orders of magnitude cheaper than the current scan / join based path.

Solution

Add a fast path in DeleteFromPaimonTableCommand for the pk-upsert delete:

  • If the condition is a conjunction of pk = literal / pk IN (literals) covering all primary key columns: extract keys from the condition and write -D rows directly (with a config to cap the driver-side cartesian expansion, falling back to scan when exceeded).
  • If the condition is pk IN (subquery) covering all primary key columns: use the subquery result as the key DataFrame, fully distributed.
  • Any other condition falls back to the existing scan-based path, so behavior stays unchanged.

Keys absent from the table are harmless since the -D records simply merge away in compaction.

I have a working implementation with tests, will submit a PR.

Anything else?

No response

Are you willing to submit a PR?
  • I'm willing to submit a PR!
Langage dominant
Java
Étoiles
3.4k
Forks
1.4k
Merge moyen
1 j 14 h
PR mergées (30 j)
468

Guide de contribution

Aucun guide de contribution indexé pour ce dépôt

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 apache/paimon

Toutes les issues de apache/paimon

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

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