pingcap/tidb

Executor, Planner: convert in_subquery to hash joins when in_subquery just involves one column

Open

#13.972 aperta il 9 dic 2019

Vedi su GitHub
 (1 commento) (0 reazioni) (1 assegnatario)Go (6186 fork)batch import
help wantedsig/executionsig/plannertype/enhancement

Metriche repository

Star
 (40.090 star)
Metriche merge PR
 (Merge medio 14g 4h) (346 PR mergiate in 30 g)

Descrizione

Feature Request

Is your feature request related to a problem? Please describe:

select * from S where S.a in (select a from T); where s.a and t.a are nullable. in TiDB, this query is converted to a NestLoopJoin, which is time-consuming. in Mysql, this query is transformed into looking up a materialized table using an equal key, which is like a hash join.

Describe the feature you'd like:

Supporting a nullable join key in current hash join of TiDB, NOTE only one key. Otherwise, it should take the NestLoopJoin .

Describe alternatives you've considered:

Teachability, Documentation, Adoption, Migration Strategy:

https://dev.mysql.com/doc/refman/8.0/en/subquery-materialization.html

Guida contributor

Direzione di ricerca
Studia l'implementazione del hash join in TiDB, concentrandoti su come vengono attualmente gestite le chiavi nullable. Modifica la logica dell'hash join per supportare una singola colonna nullable quando si converte una sottoquery IN in un hash join, come in MySQL.
Tech stack
go
Dominio
backend
Tipo issue
Funzionalità
DifficoltàQuanto dovrebbe essere impegnativa per un nuovo contributor.
2
Tempo stimatoTempo stimato per completare e verificare uno scope piccolo.
Mezza giornata
Stato attivitàQuanto è probabile che la issue sia ancora attiva e reviewable.
Attiva
ChiarezzaQuanto chiaramente la issue descrive problema, scope e risultato atteso.
Chiara
Prerequisiti
Go
Adatta ai principiantiQuanto la issue è adatta a contributor alla prima esperienza.
60