Administrace komentářů

Tak ještě jednou a detailněji:

Tvrzení první: pokud před operací sort budete dělat v selectu jinou libovolnou operaci tak si při ní dotyčný case předpočítáte a sort pak může být přeložen téměř úplně stejně jako v případě existence fráze null first/last. Důsledek prvního faktu: Aby bylo možné zlepšení, tak sort musí být první (jediná) operace.

Tvrzení druhé: Aby byl sort s null first efektivnější než case musí dojít k využití btree-indexu (řazeného dle hodnoty nikoliv hashe). Při nevyužití indexu bude složitost stejná v obou případech a to O(n*log n) bez ohledu na počet, a typ vstupů ve frázi order by.

Tvrzení třetí: Aby mělo využití indexu smysl nesmí se vám výsledek vejít do paměti. Pokud se vám tabulka vejde do paměti pak v rámci natažení do paměti uděláte i ten case a dále pokračujete podle tvrzení jedna. Pokud si někdo myslí že přes index to bude i v tomto případě rychlejší, tak je potřeba si uvědomit, že kromě kompletní tabulky musíte do paměti dostat z disku i ten index. O přístupu přes index by možná dalo polemizovat. Já se přikláním k názoru že cena čtení indexu z disku bude větší než cena kompletního třídění v paměti. Bavíme se o třídění relativně malé tabulky, která se vejde do paměti.

Tvrzení čtvrté: Pokud musí být sort první operací (viz tvrzení první a druhé) pak musí komutovat se všemi předchozími operacemi, tak aby se dostal na první místo a bylo možné index využít. Jediný takový případ je, že předchází jediná operace where, protože je to jediná operace, která je schopna zachovat relativní pořadí vět, které vypade ze sort operace. A navíc tato optimalizace musí podporována optimizérem. I zde by možná šlo polemizovat, že lze postavit join algoritmus, který by pořadí zachovával, ale obávám se, že na toto databáze běžně nepodporují.

Otázka zůstává: Z čeho plyne to tvrzení o snížené výkonosti? Rád se nechám poučit.