Vyreseno: Indexy v PostgreSQL

Martin Kavalec xkavm04 na vse.cz
Pondělí Říjen 2 00:09:39 CEST 2000


On Sun, Oct 01, 2000 at 03:01:33AM +0000, Jakub Labath wrote:
> Zdravim,
> pouzivam PostgreSQL 7.0.2
> urobil som si taku tabulku co kolega napchal ju nieco vyse 700000
> riadkami a mal rovnake priznaky ,snad az na to vytvorenie 
> indexu na pole father potom mi explain vyhadzuje nieco taketo

Taky jsem tu tabulku zkusil vic zaplnit a uz to ty indexy pouziva.
Zkratka optimizer usoudi, ze na tak male mnozstvi dat se nevyplati
pouzivat index. Pote, co jsem pridane uzly zase odmazal a dal
VACUUM, opet se preslo na sekvencni vyhledavani.

Na sekvencni prochazeni se prejde po vytvoreni noveho indexu
nejspis proto, ze se pri teto operaci prepracuji statistiky, ze
kterych vychazi optimizer. Kdyz na teze tabulce misto
"CREATE INDEX nodes_father" pustim VACUUM, ma to stejny ucinek.
Takze zahada je vyresena. No, neni ten postgres krasny? :-)

> Pozrel som sa do dokumentacie (Using Explain) a ohladne rows som nasiel
> toto
> Estimated number of rows output by this plan node.
> a kusok pod tym zas toto
> Rows output is a little tricky because it is not the number of rows
> processed/scanned by the query --- it is usually less, reflecting the
> estimated
> selectivity of any WHERE-clause constraints that are being applied at
> this node.
> 
> No neviem ci to je moja anglictina ale moc tomu nerozumiem.
> Na jednej strane to ma vracat predpokladany pocet vystupnych riadkov
> a potom zas cosi o riadkoch ktorymi prechadza query.

To jen upozornuje, ze pocet radku vystupujich z daneho uzlu muze
byt mensi nez pocet radku, ktere je nutno zpracovat. Pro sestaveni
planu je potreba zohlednit oboji, proto rows obsahuji pocet
vystupnich radku, zatimco pocet radku, ktere se musi projit je
zohlednen v cost.

 
> Inak co sa tyka vykonnosti rychlost bola rovnaka ci som robil where id
> = 12 alebo where id = 700000.
> Rychlost som meral ocami :-)

Ja taky, je to OK, i ta aplikace nad tim bezi porad stejne rychle.

Zdravi
martin


Další informace o konferenci Databases