1

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)

2

Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli

Odświeżyłeś statystyki?
Jak wyglada rozkład danych w indexowanej kolumnie tzn ile jest różnych wartości w tej kolumnie.

3

Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli

4

Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli

Moje dociekania doprowadziły mnie do postawienia takich wniosków:

1. postgresql.conf

- relacja seq_page_cost do random_page_cost, im bliższa 1:1 albo wręcz random_page_cost mniejsze niz 1, tym większa szansa, że optimizer wybierze index niż seqscan.
- effective_cache_size, im większe tym częściej optimizer wybierze index

2. 100M tabela z unikalnym ID numerycznym została przesortowana indexem, a nie seqscan. To doprowadziło do konkluzji, że duplikowana, textowa kolumna jako ID jest lepiej sortowana przez seqscan, niż index (btree).

5

Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli

To że optymalizator nie wybierał indexu z czegoś wynika, możliwe że miał niekonkretne dane.
Próbowałeś coś takiego:

ALTER TABLE tabela ALTER COLUMN kolumna SET STATISTICS 50000;

?