Administrace komentářů

Tak prosím, tohle je další průšvih:

db_pokus=> explain select * from dummy where number <= all ( select number from dummy );
                                       QUERY PLAN
----------------------------------------------------------------------------------------
 Seq Scan on dummy  (cost=200006967.93..1265785714.93 rows=180224 width=8)
   Filter: (subplan)
   SubPlan
     ->  Materialize  (cost=100006967.93..100011980.41 rows=360448 width=8)
           ->  Seq Scan on dummy  (cost=100000000.00..100005199.48 rows=360448 width=8)
(5 rows)

S indexem by něco takového byla prostě hračka, otázka zlomku vteřiny. Vložil jsem do tabluky dummy cca 360000 záznamů a pak jsem spustil ten dotaz. To bylo před deseti minutami a dotaz stále běží. Tedy se opravdu jedná o závažný problém plánovače.

Tohle je ale zklamání na celé čáře. K čemu je vlastně dobrý DBMS, který není schopen získat minimální prvek z indexu v logaritmickém čase??? Jasně, není tak zle, select min( number ) from dummy; je to, co ve skutečnosti chci. To funguje správně a efektivně.

Ale jak už jsem tu jednou psal: U automaticky generovaného SQL kódu prostě někdy vznikne ta výše uvedená ošklivá věc, která v podstatě pošle celou aplikaci do háje už na relativně malých datech.

Čím to může být?

• Nějaký problém s izolací transakcí? Že by se optimalizátor bál toho vnořeného poddotazu? Zkusil jsem stejný dotaz znovu na všech úrovních, ale nic se nezměnilo. Dotaz byl naplánován vždy nejhůře, jak to vůbec šlo. (Kromě toho si myslím, že plánování dotazu vůbec nesouvisí s úrovněmi izolace.)
• Mám snad vypnuté nějaké pokročilé funkce optimalizátoru? Myslím, že ani tady problém nebude...

Tohle je ale fakt divné. Nemáte náhodou někdo přístup k Oracle? Zajímalo by mě, jak by EXPLAIN dopadl tam.