Administrace komentářů

Bavíme se o výkonu dotazu na konkrétní databázi: a na té konkrétní databázi byla prostě Tvá argumentace že něco znevýhodňuju nepravdivá.

Ano - delete 10GB souboru je chvíle, protže ve filesystému není třeba označovat volné bloky. Tady se ovšem bavíme o 8B záznamu mazaném v databázi, kde JE třeba na tu stránku sahat tak jako tak (označit smazaný záznam). Vzhledem k tomu, že výkon DB je defakto podmíněn množstvím IO, které se u DB nezmění, zatímco u filesystému ano, je příměr nesmyslný.

--

V tom, že se zápisy mohou cachovat máš pravdu - nicméně vzhledem k tomu, že se jedná v obou případech o stejné diskové operace (zapisují se stejná data, upravuje index stejně atd..), tak to nemá vliv. Zápis také probíhá najednou a může být odložený, a narozdíl od čtení se zapisuje do diskové cache, což je mnohem rychlejší (samozřejmě to přestává platit v případě 100% vytížení disku, ale to v tomto případě není). Takže toto cachování se na tom, že jeden dotaz běží třikrát rychlejc než druhej neprojeví.

Navíc i kdyby projevilo, tak jestli někdo dělá více zápisů a tedy více šetřil, tak deset postupných insertů. Takže jestli to cachování mění poměry mezi výkonností dotazů, tak to rozdíl zmenšuje. Takže tímdle to rozhodně neomluvíš.

---

To, proč Ti vyšel čas stejnej, je jednoduchý: režie PLPGSQL kódu zdaleka převýší režii čas dotazu. Prostě si zvolil naprosto nesmyslnej test. Když to napíšeš alespoň jako sql funkci, tak už je rozdíl znatelnej:

create function bnch(r integer) returns void language sql as
$$
   INSERT INTO bench(a,b) VALUES 
		($1*20+1 ,$1+1),($1*20+2 ,$1+2),
		($1*20+3 ,$1+3),($1*20+4 ,$1+4),
		($1*20+5 ,$1+5),($1*20+6 ,$1+6),
		($1*20+7 ,$1+7),($1*20+8 ,$1+8),
		($1*20+9 ,$1+9),($1*20+10 ,$1+10);
   DELETE FROM bench WHERE a IN ($1*20+1,$1*20+2,$1*20+3,$1*20+4,$1*20+5,$1*20+6,$1*20+7,$1*20+8,$1*20+9,$1*20+10) AND b between $1+1 and $1+19;
$$;

create function bnch2(r integer) returns void language sql as
$$
   INSERT INTO bench(a,b) VALUES ($1*20+1, $1+1);
   INSERT INTO bench(a,b) VALUES ($1*20+2, $1+2);
   INSERT INTO bench(a,b) VALUES ($1*20+3, $1+3);
   INSERT INTO bench(a,b) VALUES ($1*20+4, $1+4);
   INSERT INTO bench(a,b) VALUES ($1*20+5, $1+5);
   INSERT INTO bench(a,b) VALUES ($1*20+6, $1+6);
   INSERT INTO bench(a,b) VALUES ($1*20+7, $1+7);
   INSERT INTO bench(a,b) VALUES ($1*20+8, $1+8);
   INSERT INTO bench(a,b) VALUES ($1*20+9, $1+9);
   INSERT INTO bench(a,b) VALUES ($1*20+10, $1+10);
   DELETE FROM bench WHERE a=$1*20+1;
   DELETE FROM bench WHERE a=$1*20+2;
   DELETE FROM bench WHERE a=$1*20+3;
   DELETE FROM bench WHERE a=$1*20+4;
   DELETE FROM bench WHERE a=$1*20+5;
   DELETE FROM bench WHERE a=$1*20+6;
   DELETE FROM bench WHERE a=$1*20+7;
   DELETE FROM bench WHERE a=$1*20+8;
   DELETE FROM bench WHERE a=$1*20+9;
   DELETE FROM bench WHERE a=$1*20+10;
$$;

explain analyze bench(1111);
explain analyze bench(2222);

Samozřejmě čísla si měň jak chceš, vychází to +- furt stejně. Mě to vychází 1.5ms ku 1.9ms. SQL funkce má samozřejmě režii (tadle nejde ani inlinovat), takže výslednej poměr bude značně větší, ale už takhle to dokazuje, že tam rozdíl je.

--

Ohledně dotazů s between a bez: psal jsi že vymažeš databázi, nic víc. Vycházím z toho že píšeš (a když tvrdíš takový s odpuštěním blbiny, tak pak už Tě podezřívám z každý blbosti). I když přistoupím na Tvoji pochybnou metodiku (teda promazávat db odmítám, to je fakt padlý na hlavu, výkon db stojí na tom, že si používaný data v drží v paměti) a měřil jeden dotaz, tak u mne i jeden dotaz s BETWEEN trvá kratší dobu než bez: typická doba pro BETWEEN dotaz je 0.0090ms, bez BETWEEN 0.0100ms. Ověřeno na mnoho dotazech na různé datové stránky.

V jednom máš trochu pravdu: vypadá to, že když dělám náhodné dotazy přes celou databázi, tak je sice BETWEEN rychlejší, ale má o něco větší sklony k občasnýmu zalagování. Pochopitelně, protože používá další index, kterej nemusí bejt v paměti (zkouším na vývojový konfiguraci co ji moc k dispozici nemá). Tendle delší čas se asi projevil u Tvýho testu na čerstvý databázi, kde to bude mít stejnej problém.

Jenže v typickém použití se edituje pouze malá množina aktuálních dat (kdo šahá x let zpátky?) a navíc právě ta data, která db před chviličkou načetla pro editaci. Takže správná metodika je spustit dotaz dvakrát za sebou a brát druhej čas. V tom případě mi to vyjde cca 0.033ms ku 0.055ms a naopak lagovat začne dotaz bez BETWEEN! což je opět pochopitelný, protože při druhym dotazu je ten interval dle kterýho se selektí určitě v paměti, zatímco select přes id jde hrabat do bitmapovýho indexu, kterej musí projít celej a paměťová náročnost je ve výsledku větší.

Jak jsem již psal: to, že při dotazu s BETWEEN volí databáze jinej plán, smysl prostě má, DB to nedělá pro nic za nic ale proto, že tu podmínku s BETWEEN umí s výhodou využít.