[perf] Scans et transferts évitables : COUNT(*) systématiques, schéma collecté deux fois, colonnes ignorées embarquées dans le join, collect intégral des doublons

[VincentGuyader]

Contexte

Quatre coûts évitables autour du join et des comptages, sensibles surtout sur le chemin lazy/Parquet :

1. Deux COUNT(*) systématiques : validate_row_counts() (R/validation.R) exécute lazy_nrow() sur les deux tables à chaque appel, même quand check_count: false et qu'une clé est fournie — cas où ces comptes ne servent à rien (ils ne sont consommés que par le chemin positionnel ou le check de comptage). Deux full scans gratuits par comparaison sur gros Parquet.
2. Schéma head-0 collecté deux fois quand path = NULL : une fois dans write_rules_template() (l.49) et une fois dans le corps de compare_datasets_from_yaml() (l.299-300) — un aller-retour DB évitable.
3. Colonnes inutiles dans le join : left_join embarque aussi les ignore_columns et les colonnes extra des deux côtés, jamais comparées, puis les transporte jusque dans l'agent pointblank — surcoût mémoire sur tables larges. Un select(all_of(c(key, common_cols))) avant le join les élimine.
4. find_duplicate_keys() lazy collecte tous les groupes dupliqués (R/duplicate_keys.R : collect() après filter(n > 1)) alors que seuls 2 agrégats et 3 exemples sont nécessaires — transfert massif si des millions de clés sont dupliquées ; agréger côté SQL + head(3).

Reprex (illustration du point 1)

library(datadiff); library(duckdb); library(dplyr)
con <- dbConnect(duckdb())
# sur un vrai Parquet volumineux, ces deux COUNT(*) se voient au profiler DuckDB
ref <- tbl(con, "read_parquet('gros.parquet')")
compare_datasets_from_yaml(ref, ref, key = "id")  # check_count FALSE par défaut avec clé

Critères de succès

• lazy_nrow() appelé uniquement si check_count est actif ou si le chemin est positionnel.
• Un seul collect de schéma head-0 par table et par appel.
• Le cmp joint ne contient que clé + colonnes comparées ; extraits d'échec inchangés.
• find_duplicate_keys() lazy : agrégats calculés en SQL, au plus 3+1 groupes rapatriés.
• Verdicts et warnings byte-identiques sur la suite de tests ; gains visibles au bench lazy.