Hlavní navigace

Názor k článku Zákys jménem flattening od Martin Kavalec - Taky mi to připadá jako fundamentalismus říct, že...

  • Článek je starý, nové názory již nelze přidávat.
  • 8. 3. 2007 21:50

    Martin Kavalec (neregistrovaný)
    Taky mi to připadá jako fundamentalismus říct, že hinty jsou špatné a basta. A v tomto světle je pak čiré farizejství, když si tam jeden hint převlečený za OFFSET nechají; když už optimalizovat, tak pořádně a OFFSET 0 by se měl vyhodnotit jako zbytečná klauzule, ne? Když to dotáhnu ad absurdum, tímto stylem by se taky mohlo zakazovat použití indexu přidáním "AND sloupec=sloupec" do klauzule WHERE.

    Ne vždycky je nutné nad tabulkou vytvářet statistiky -- např. při různých agregacích a transformacích dat pro datový sklad. Např. vím, že ve vstupní tabulce mám ke každému identifikátoru max. 3 záznamy a unikátních identifikátorů jsou tam třeba 3 miliony a tuto tabulku potřebuju sumarizovat podle těch ID. Planner to chce groupovat hashováním, protože netuší, ze těch unikátních identifikatrů je tolik. Buď mu můžu říct, ať si spočítá statistiky, anebo připsat na konec dotazu kouzelné "option (order group)", čímž mu poradím, že je rychlejší si tabulku sesortovat a pak už jet sekvenčně. (což se testováním ukázalo jako rychlejší a po vytvoření statistik na to planner přijde taky) Ale vzhledem k tomu, že tato operace je jednorázová, pak se tabulka smaže a příště se bude agregovat zase nová tabulka, je to vytváření statistik trochu drahý "hint". (ten zápis hintu je pro MS SQL, čímž taky odpovídám na dotaz někde v diskuzi, jestli MS SQL má hinty)

    Každopádně, uznávám, že je to dost specifický případ. Asi bych si hodně rozmýšlel použít hint někde v kódu aplikace, kde fakt hrozí, že sice zrovna teď mi to pomůže, ale až se změní charakter dat, tak si na tom ta aplikace vyláme zuby, kdežto se statistikama se tomu prostě přizpůsobí.

    Jinak pro zajimavost, někdy před rokem a půl jsem u Postgresu narazil na toto zajímavé chování:

    explain select neco_id from tabulka where neco_id between 100000 and 150000 order by neco_id;

    navrhoval použít seq scan tabulky (a bylo to pomalé, v tabulce bylo tusim cca 700 tis. záznamů).
    Pokud jsem to přepsal na

    select * from
    (select neco_id from tabulka where neco_id betweeen 100000 and 125000
    union all
    select neco_id from tabulka where neco_id betweeen 125001 and 150000) x
    order by neco_id

    tak uz se pouzil index scan (+ append).
    Na tom, ze hinty jsou spatne asi neco bude, protoze me to aspon prinutilo podivat se do manualu a upravit parametr random_page_cost a pak se pouzil index i v prvnim pripade. Ten analyzer vykonostnich charakteristik disku, jak nekdo v diskuzi navrhoval, asi neni spatny napad :)