Temat: [solved] Optimizer nie używa indexu na 46M+ tabeli
Hej,
Mam problem, którego nie mogę rozgryźć.. Otóż mam założony index na kolumnie, po której często będę sortował/agregował/łączył. Doszedłem do wniosku, że optymalnym dla mnie indexem na tej tabeli będzie btree (defaultowy index postgresa).
Otóż tabela ma 125M i podczas robienia testów (sortowanie bez indexu vs sortowanie z indexem) nie zauważyłem żadnej różnicy w czasie sortowania. W obu przypadkach wyszło około 03:10 godzin. Test polegał na "create table as select * order by".
To samo miałem z 5M tabelą. Co się okazało.. Że musiałem dopisać linijkę
set enable seqscan=off;
przed selectem. I z początku na 5M tabeli z 3:36 minut zeszło mi do 40 sekund! Czyli musiałem zmusić postgresa do używania indexu, ponieważ optimizer z początku go nie uznał.
Tak samo myślałem, że będzie z 125M tabelą, ale nie.. testowałem EXPLAIN'em różne konfiguracje z limitem. Wyszło, że jak dam limit 45,125,000, to jeszcze optimizer korzysta z indexu, jeśli go zmuszę. Natomiast powyżej tej liczby już zawsze leci SEQSCAN.
Czy jest jakiś sposób, żeby DEFINITYWNIE zmusić postgresa do skorzystania z indexu??
Mam wrażenie, że może chodzić o jakąś konkretną konfigurację postgresql.conf, czy tak?
Ostatnio edytowany przez Myziot (2010-01-27 19:24:18)