<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="http://www.w3.org/2005/Atom">
	<title type="html"><![CDATA[Forum PostgreSQL - [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
	<link rel="self" href="http://forum.postgresql.org.pl/extern.php?action=feed&amp;tid=382&amp;type=atom"/>
	<updated>2010-04-19T23:27:38Z</updated>
	<generator>PunBB</generator>
	<id>https://forum.postgresql.org.pl/viewtopic.php?id=382</id>
		<entry>
			<title type="html"><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link rel="alternate" href="https://forum.postgresql.org.pl/viewtopic.php?pid=1980#p1980"/>
			<content type="html"><![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]
?]]></content>
			<author>
				<name><![CDATA[letni_deszczyk]]></name>
				<uri>https://forum.postgresql.org.pl/profile.php?id=1091</uri>
			</author>
			<updated>2010-04-19T23:27:38Z</updated>
			<id>https://forum.postgresql.org.pl/viewtopic.php?pid=1980#p1980</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link rel="alternate" href="https://forum.postgresql.org.pl/viewtopic.php?pid=1761#p1761"/>
			<content type="html"><![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).]]></content>
			<author>
				<name><![CDATA[Myziot]]></name>
				<uri>https://forum.postgresql.org.pl/profile.php?id=947</uri>
			</author>
			<updated>2010-01-27T17:23:48Z</updated>
			<id>https://forum.postgresql.org.pl/viewtopic.php?pid=1761#p1761</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link rel="alternate" href="https://forum.postgresql.org.pl/viewtopic.php?pid=1750#p1750"/>
			<content type="html"><![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.]]></content>
			<author>
				<name><![CDATA[Myziot]]></name>
				<uri>https://forum.postgresql.org.pl/profile.php?id=947</uri>
			</author>
			<updated>2010-01-26T09:16:54Z</updated>
			<id>https://forum.postgresql.org.pl/viewtopic.php?pid=1750#p1750</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[Odp: [solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link rel="alternate" href="https://forum.postgresql.org.pl/viewtopic.php?pid=1738#p1738"/>
			<content type="html"><![CDATA[Odświeżyłeś statystyki?
Jak wyglada rozkład danych w indexowanej kolumnie tzn ile jest różnych wartości w tej kolumnie.]]></content>
			<author>
				<name><![CDATA[rski]]></name>
				<uri>https://forum.postgresql.org.pl/profile.php?id=26</uri>
			</author>
			<updated>2010-01-25T15:36:40Z</updated>
			<id>https://forum.postgresql.org.pl/viewtopic.php?pid=1738#p1738</id>
		</entry>
		<entry>
			<title type="html"><![CDATA[[solved] Optimizer nie używa indexu na 46M+ tabeli]]></title>
			<link rel="alternate" href="https://forum.postgresql.org.pl/viewtopic.php?pid=1737#p1737"/>
			<content type="html"><![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?]]></content>
			<author>
				<name><![CDATA[Myziot]]></name>
				<uri>https://forum.postgresql.org.pl/profile.php?id=947</uri>
			</author>
			<updated>2010-01-25T15:02:02Z</updated>
			<id>https://forum.postgresql.org.pl/viewtopic.php?pid=1737#p1737</id>
		</entry>
</feed>
