Mi sono perso tutte le risposte che avevate gia' dato, ho letto solo
la domanda iniziale e sono partito a razzo, l'avevo detto che non
dovevo rispondere alle 10 e mezza di sera :)
Ora le ho lette e mi spiego anche cio' che dicevo nel mio primo reply,
mi sembrava strano che il query optimizer scegliesse di fare un
Sort-Merge Join senza avere entrambe le chiavi di join indicizzate...
Infatti poi alla fine torna a fare il Nested Loop sull'indice
dell'inner table del join.
Comunque, per curiosita' personale, c'e' o non c'e' l'indice su r.id?
Perche' se non c'e', metticelo, postgresql a quel punto ti scegliera'
il Merge Join che e' anche piu' veloce se entrambi gli attributi del
join sono indicizzati.
Uh? ;)
Come giustamente diceva Chris si tratta del classimo problema di
statistiche insufficienti affinché il planner stimi correttamente il
numero di righe. E' questa la causa del plan sub-ottimale, niente di
più, niente di meno :)
