<html>
<head>
</head>
<body class='hmmessage'><div dir='ltr'>
<style><!--
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 12pt;
font-family:Calibri
}
--></style>
<div dir="ltr">[...]<br><div>> <br>> Per capire, mi sono andato a vedere la query che sqlalchemy genera, ed è<br>> come segue:<br>> <br>> "SELECT a.id AS a_id, a.col AS a_col FROM a, arel WHERE ? = arel.id1 AND<br>> a.id = arel.id2", la_mia_id<br>> <br>> Provando a chiamare direttamente questa query direttamente con sqlite,<br>> in effetti ottengo lo stesso effetto che usando l'ORM di slqalchemy.<br>> <br>> Ora, le mie conoscenze/ricerche di SQL sono sufficienti per farmi capire<br>> che questa è una JOIN implicita, e qual'è la sua logica. Però non<br>> capisco:<br>> 1) dal punto di vista implementativo: com'è possibile che una JOIN sia<br>> così più lenta di svariate SELECT che fanno (concettualmente, per quel<br>> che ne posso capire) esattamente lo stesso lavoro?!<br>> 2) ammesso che debba essere così, cosa impedisce a sqlalchemy di usare<br>> le stesse SELECT che uso io, per recuperare esattamente la stessa roba?!<br>[...]<br>> Pietro<br><br>Sqlite accede a AREL cercando id1=la_mia_id: in assenza di indice su AREL.id1 effettua una ricerca lineare. Supponiamo pure che questo per scorrere tutta la tabella serva un decimo di secondo.<br>Per ogni riga ottenuta accede alla tabella A cercando quale "id" batta: in assenza di indice su A.id effettua una ricerca lineare, ogni volta impiegando un decimo di secondo per scorrere tutta la tabella.<br>Ora, con milioni di decimi di secondo si si arriva facilmente a qualche giorno di esecuzione...<br><br>Aggiungi due indici.<br>M.<br><br></div></div>
</div></body>
</html>