PostgreSQL 8.1 i indeksowanie kluczy obcych.
Marek - 12-11-2006 00:38
PostgreSQL 8.1 i indeksowanie kluczy obcych.
Witam,
Mam pytanie odnośnie rodzaju indeksów jakie powinienem stosować wobec kluczy
obcych w tabelach. Czy stosowanie 'hash" jest najwłaściwsze z uwagi na to,
że klucze obce zawsze porównujemy znakiem "=" a nigdy < <= itp. Zauważyłem
też, że dla tabeli:
CREATE TABLE subcategory_helper
(
parent_id int4 NOT NULL,
child_id int4,
doc_template_id int4,
calculate_group_item_id int4,
path_parent text NOT NULL,
path_child text NOT NULL,
FOREIGN KEY (parent_id) REFERENCES category (category_id) MATCH FULL ON
DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (child_id) REFERENCES category (category_id) MATCH FULL ON
DELETE CASCADE ON UPDATE CASCADE,
FOREIGN KEY (doc_template_id) REFERENCES doc_template (doc_template_id)
MATCH FULL ON DELETE SET NULL ON UPDATE CASCADE,
FOREIGN KEY (calculate_group_item_id) REFERENCES calculate_group_item
(calculate_group_item_id) MATCH FULL ON DELETE SET NULL ON UPDATE CASCADE
);
CREATE INDEX subcategory_helper_idx1 ON subcategory_helper USING HASH
(parent_id);
CREATE INDEX subcategory_helper_idx2 ON subcategory_helper USING HASH
(child_id);
CREATE INDEX subcategory_helper_idx3 ON subcategory_helper USING HASH
(doc_template_id);
CREATE INDEX subcategory_helper_idx4 ON subcategory_helper USING HASH
(calculate_group_item_id);
indeks subcategory_helper_idx1 przy użyciu btree miał rozmiar dla
przykładowych danych 800kB, drugi indeks: 900kB itd. a obecnie przy metodzie
hash wszystkie cztery mają dokładnie po 32kB przy tej samej ilości danych.
Czy coś jest źle bo nie wierzę w taki zbieg okoliczności?
Po drugie: czy metoda hash jest efektywna przy wyszukiwaniu równości z
null'em? Chodzi mi o stosowanie ISNULL zamiast "=".
--
Pozdrawiam,
Marek
Marek - 12-11-2006 00:38
Przeprowadziłem jeszcze jeden test, którego wyniki zaskoczyły mnie na maxa.
Otóż dokonałem analizy 3 przypadków dla zapytania SQL w postaci:
explain select * from category c, subcategory_helper sh where
sh.parent_id=c.category_id;
Przypadek 1.
Indeks subcategory_helper_idx1 jest typu hash. Otrzymałem:
Hash Join (cost=3.30..27.64 rows=369 width=134)
Hash Cond: ("outer".parent_id = "inner".category_id)
-> Seq Scan on subcategory_helper sh (cost=0.00..17.10 rows=710
width=80)
-> Hash (cost=3.04..3.04 rows=104 width=54)
-> Seq Scan on category c (cost=0.00..3.04 rows=104 width=54)
Przypadek 2.
Indeks subcategory_helper_idx1 jest usunięty. Otrzymałem:
Hash Join (cost=3.30..27.64 rows=369 width=134)
Hash Cond: ("outer".parent_id = "inner".category_id)
-> Seq Scan on subcategory_helper sh (cost=0.00..17.10 rows=710
width=80)
-> Hash (cost=3.04..3.04 rows=104 width=54)
-> Seq Scan on category c (cost=0.00..3.04 rows=104 width=54)
Przypadek 3.
Indeks subcategory_helper_idx1 jest typu btree. Otrzymałem:
Hash Join (cost=3.30..15.66 rows=164 width=134)
Hash Cond: ("outer".parent_id = "inner".category_id)
-> Seq Scan on subcategory_helper sh (cost=0.00..9.15 rows=315 width=80)
-> Hash (cost=3.04..3.04 rows=104 width=54)
-> Seq Scan on category c (cost=0.00..3.04 rows=104 width=54)
Wygląda na to, że brak indeksu na kluczach obcych nie zmniejsza wydajności
wyszukiwania względem przypadku z zastosowaniem indeksu typu HASH. Gdy
zastosuję indeks BTREE to widać, że koszt operacji spada z 17.10 do 9.15.
Mam w związku z tym pytanie kolejne do zadanych wcześniej - dlaczego metoda
hash nie wnosi niczego? No i kluczowe pytanie: jaki typ indeksu dla pól
będących kluczami obcymi (zawsze są to pola liczbowe)?
Łukasz - 12-11-2006 00:39
Użytkownik "Marek" <marek1967@spam.interia.pl> napisał w wiadomości
news:ef3ijo$am8$1@achot.icm.edu.pl...
> Przeprowadziłem jeszcze jeden test, którego wyniki zaskoczyły mnie na
> maxa. Otóż dokonałem analizy 3 przypadków dla zapytania SQL w postaci:
>
>
> Wygląda na to, że brak indeksu na kluczach obcych nie zmniejsza wydajności
> wyszukiwania względem przypadku z zastosowaniem indeksu typu HASH. Gdy
> zastosuję indeks BTREE to widać, że koszt operacji spada z 17.10 do 9.15.
> Mam w związku z tym pytanie kolejne do zadanych wcześniej - dlaczego
> metoda hash nie wnosi niczego? No i kluczowe pytanie: jaki typ indeksu dla
> pól będących kluczami obcymi (zawsze są to pola liczbowe)?
Hmmm indeksy na b-drzewach są chyba nie do pobicia jeśli chodzi o
wydajność..
Z tego co pamiętam indeksy oparte na hashach wyjątkowo kiepsko zachowują się
gdy wartości się często powtarzają.
Marek - 12-11-2006 00:39
> Hmmm indeksy na b-drzewach są chyba nie do pobicia jeśli chodzi o
> wydajność..
> Z tego co pamiętam indeksy oparte na hashach wyjątkowo kiepsko zachowują
> się gdy wartości się często powtarzają.
Hmmm ... ale to jest sprzeczne z tym co dokumentacja mówi
http://www.postgresql.org/docs/8.1/i...xes-types.html
Tam napisano, że hash-indeksy stosuje się wyłącznie gdy stosowane są
operatory "=" lecz nie napisano nic więcej na ten temat, nawet tego, że
indeks jest pozbawiony sensu stosowania w jakimkolwiek przypadku. No bo
chyba na to wychodzi?
Rafal M - 12-11-2006 00:39
Marek wrote:
>> Hmmm indeksy na b-drzewach są chyba nie do pobicia jeśli chodzi o
>> wydajność..
>> Z tego co pamiętam indeksy oparte na hashach wyjątkowo kiepsko
>> zachowują się gdy wartości się często powtarzają.
>
> Hmmm ... ale to jest sprzeczne z tym co dokumentacja mówi
> http://www.postgresql.org/docs/8.1/i...xes-types.html
> Tam napisano, że hash-indeksy stosuje się wyłącznie gdy stosowane są
> operatory "=" lecz nie napisano nic więcej na ten temat, nawet tego, że
> indeks jest pozbawiony sensu stosowania w jakimkolwiek przypadku. No bo
> chyba na to wychodzi?
"Hash index" vs. "b-tree index" (PostgreSQL 8.0)
http://archives.postgresql.org/pgsql...5/msg00370.php
Marek - 12-11-2006 00:39
> "Hash index" vs. "b-tree index" (PostgreSQL 8.0)
>
> http://archives.postgresql.org/pgsql...5/msg00370.php
Aha ... czyli moje obserwacje są słuszne, że hash index to pomyłka.
Dzięki za info :-)
Łukasz - 12-11-2006 01:33
Użytkownik "Marek" <marek1967@spam.interia.pl> napisał w wiadomości
news:ef5mos$7d6$1@achot.icm.edu.pl...
>
> Hmmm ... ale to jest sprzeczne z tym co dokumentacja mówi
> http://www.postgresql.org/docs/8.1/i...xes-types.html
> Tam napisano, że hash-indeksy stosuje się wyłącznie gdy stosowane są
> operatory "=" lecz nie napisano nic więcej na ten temat, nawet tego, że
> indeks jest pozbawiony sensu stosowania w jakimkolwiek przypadku. No bo
> chyba na to wychodzi?
Tam nie pisze że hash-indeksy są szybsze... Prawdę mówiąc trudno jest mi
wyobrazić sobie sytuację w której hash-indeks mógłby być lepszy, ale moja
wyobraźnia jest limitowana ograniczonym doświadczeniem, więc może dla
jakichś gigantycznych tabel to się opłaca...
zanotowane.pldoc.pisz.plpdf.pisz.pleffulla.pev.pl
|
[PostgreSQL] - jak =?ISO-8859-2?Q?zabezpieczy=E6_interesy_tw?==?ISO-8859-2?Q?=F3rcy_systemu_=3F=3F=3F?=
postgresql - int/int
postgresql Select count(*) czy raczej Select count(ID)
[PostgreSQL] jak =?ISO-8859-2?Q?pobra=E6_warto=B6=E6_zwracan?==?ISO-8859-2?Q?=B1_przez_funkcj=EA=3F?=
[postgresql] INSERT OR UPDATE - jak =?ISO-8859-2?Q?b=EAdzie_na?==?ISO-8859-2?Q?jlepiej=3F?=
[postgresql] kilka =?ISO-8859-2?Q?rekord=F3w_subquery_jako_?==?ISO-8859-2?Q?string?=
[PostgreSQL] Jak =?ISO-8859-2?Q?po=B3=B1czy=E6_funkcje_z_w?==?ISO-8859-2?Q?idokiem?=
Postgres - replikcja master-master
Dopasowanie do "najlepszego" dopasowania :) [ PostgreSQL]
Problemy z =?ISO-8859-2?Q?instalacj=B1_PostgreSQL_na_syste?==?ISO-8859-2?Q?mach_Windows?=
zanotowane.pldoc.pisz.plpdf.pisz.pllubiatowo.xlx.pl
Cytat
Decede mihi sole - nie zasłaniaj mi słonca.
Gdy kogoś kochasz, jesteś jak stworzyciel świata - na cokolwiek spojrzysz, nabiera to kształtu, wypełnia się barwą, światłem. Powietrze przytula się do ciebie, choćby był mróz, a ty masz w sobie tyle radości, że musisz ją rozdawać wokoło, bo się w tobie nie mieści
Hoc fac - tak czyń.
A tergo - od tyłu; z tyłu.
I czarne włosy posiwieją. Safona |
|
