Administrace komentářů

Kdyby v souborovém systému nebylo při mazání potřeba označovat volné bloky, za chvíli vám dojde místo na disku -- budou ho zabírat smazané soubory. Volné bloky v souborovém systému se pak samozřejmě označují v metadatech, ne v datovém prostoru. Stejně to dělá i databáze.

Mně nevyšel stejný čas, v obou testech byly vaše optimalizace evidentně pomalejší. Nevidím tam nic, proč by režie PLPGSQL měla být v jednom případě větší, než ve druhém, takže ji můžu jako stejnou konstantu v obou případech odečíst.

Jste si jist, že v tom vašem příkladu použije PLPGSQL prepared statement?

Ohledně dotazů s between a bez: psal jsi že vymažeš databázi, nic víc.

Ne, nepsal. Pořád máte spoustu řečí o tom, jak mám pozorně číst - že byste si je vzal taky k srdci? Nepsal jsem o mazání databáze, ale o práci nad čistě založenou databází -- založenou posloupností 4 příkazů okopírovanou od vás. A nepsal jsem to u SELECTů s BETWEEN, ale u INSERTů a DELETEů. V případě SELECTů se totiž obsah databáze nemění, takže opakované testy lze plus mínus dělat nad stále stejnou databází.

Zkuste si ty dotazy porovnat nad nějakými reálnými daty, třeba pro sto uživatelů. Za období budete mít průměrně třeba 10 záznamů. Takže dotaz podle ID najde v indexu 10 záznamů a ty načte. Dotaz podle BETWEEN najde podle indexu 1000 záznamů, ty načte a bude je sekvenčně procházet a porovnávat s ID. No, ona to ta databáze ve skutečnosti takhle dělat nebude a sestaví plán přesně opačně, tj. načte těch 10 záznamů podle ID a pak jen zkontroluje tu BETWEEN podmínku. Takže je to jen příklad předčasné optimalizace. Navíc když už se do takové optimalizace chcete pouštět, měl byste index explicitně vytvořit jako B-tree. Dnes je to sice default, ale to se může změnit, a hash index vám pro BETWEEN bude houby platný. Když už budete v tom měnění indexu, aby se neprojevil výše popsaný problém, předělejte ho rovnou na složený index, buď user_id + datum nebo datum + id. Pak ta optimalizace začne dávat smysl. A taky začne být jasné, že má smysl se s ní zabývat až tehdy, když to bude úzké místo aplikace.