<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0">
	<channel>
		<title><![CDATA[Forum PostgreSQL - [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
		<link>https://forum.postgresql.org.pl/viewtopic.php?id=382</link>
		<description><![CDATA[Najświeższe odpowiedzi w [solved] Optimizer nie używa indexu na 46M+ tabeli.]]></description>
		<lastBuildDate>Mon, 19 Apr 2010 23:27:38 +0000</lastBuildDate>
		<generator>PunBB</generator>
		<item>
			<title><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=1980#p1980</link>
			<description><![CDATA[To że optymalizator nie wybierał indexu z czegoś wynika, możliwe że miał niekonkretne dane. 
Próbowałeś coś takiego:
[code]ALTER TABLE tabela ALTER COLUMN kolumna SET STATISTICS 50000;[/code]
?]]></description>
			<author><![CDATA[dummy@example.com (letni_deszczyk)]]></author>
			<pubDate>Mon, 19 Apr 2010 23:27:38 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=1980#p1980</guid>
		</item>
		<item>
			<title><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=1761#p1761</link>
			<description><![CDATA[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).]]></description>
			<author><![CDATA[dummy@example.com (Myziot)]]></author>
			<pubDate>Wed, 27 Jan 2010 17:23:48 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=1761#p1761</guid>
		</item>
		<item>
			<title><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=1750#p1750</link>
			<description><![CDATA[[quote=rski]Odświeżyłeś statystyki?
Jak wyglada rozkład danych w indexowanej kolumnie tzn ile jest różnych wartości w tej kolumnie.[/quote]

Tak, odświeżyłem VACUUM, ANALYZE etc.

Jeśli chodzi o duplikaty, to fakt.. jest tam jakies 65.5k unikalnych wpisów w kolumne. Każde ID duplikowane 1908 razy.]]></description>
			<author><![CDATA[dummy@example.com (Myziot)]]></author>
			<pubDate>Tue, 26 Jan 2010 09:16:54 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=1750#p1750</guid>
		</item>
		<item>
			<title><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=1738#p1738</link>
			<description><![CDATA[Odświeżyłeś statystyki?
Jak wyglada rozkład danych w indexowanej kolumnie tzn ile jest różnych wartości w tej kolumnie.]]></description>
			<author><![CDATA[dummy@example.com (rski)]]></author>
			<pubDate>Mon, 25 Jan 2010 15:36:40 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=1738#p1738</guid>
		</item>
		<item>
			<title><![CDATA[[solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link>https://forum.postgresql.org.pl/viewtopic.php?pid=1737#p1737</link>
			<description><![CDATA[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ę [code]set enable seqscan=off;[/code] 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?]]></description>
			<author><![CDATA[dummy@example.com (Myziot)]]></author>
			<pubDate>Mon, 25 Jan 2010 15:02:02 +0000</pubDate>
			<guid>https://forum.postgresql.org.pl/viewtopic.php?pid=1737#p1737</guid>
		</item>
	</channel>
</rss>
