<?xml version="1.0"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="cs">
	<id>http://postgres.cz/index.php?action=history&amp;feed=atom&amp;title=Optimalizace_vyhodnocen%C3%AD_v%C3%BDraz%C5%AF_v_PL%2FpgSQL</id>
	<title>Optimalizace vyhodnocení výrazů v PL/pgSQL - Historie editací</title>
	<link rel="self" type="application/atom+xml" href="http://postgres.cz/index.php?action=history&amp;feed=atom&amp;title=Optimalizace_vyhodnocen%C3%AD_v%C3%BDraz%C5%AF_v_PL%2FpgSQL"/>
	<link rel="alternate" type="text/html" href="http://postgres.cz/index.php?title=Optimalizace_vyhodnocen%C3%AD_v%C3%BDraz%C5%AF_v_PL/pgSQL&amp;action=history"/>
	<updated>2026-05-13T01:35:50Z</updated>
	<subtitle>Historie editací této stránky</subtitle>
	<generator>MediaWiki 1.43.3</generator>
	<entry>
		<id>http://postgres.cz/index.php?title=Optimalizace_vyhodnocen%C3%AD_v%C3%BDraz%C5%AF_v_PL/pgSQL&amp;diff=595&amp;oldid=prev</id>
		<title>imported&gt;Pavel v 19. 10. 2020, 11:41</title>
		<link rel="alternate" type="text/html" href="http://postgres.cz/index.php?title=Optimalizace_vyhodnocen%C3%AD_v%C3%BDraz%C5%AF_v_PL/pgSQL&amp;diff=595&amp;oldid=prev"/>
		<updated>2020-10-19T11:41:09Z</updated>

		<summary type="html">&lt;p&gt;&lt;/p&gt;
&lt;p&gt;&lt;b&gt;Nová stránka&lt;/b&gt;&lt;/p&gt;&lt;div&gt;Autor: &amp;#039;&amp;#039;Pavel Stěhule&amp;#039;&amp;#039;&lt;br /&gt;
[[Category:Články]]&lt;br /&gt;
&lt;br /&gt;
Původní interpret PL/pgSQL byl napsán velice jednoduše a to tak, že veškeré výrazy převáděl na SQL příkazy, a sám o sobě realizoval pouze procedurální příkazy. Díky tomu byl programovací jazyk PL/pgSQL absolutně konzistentní s SQL prostředím ale jeho zpracování bylo poměrně pomalé - vzhledem k ostatním interpretovaným jazykům jako je Python, Perl, Lua. Postupem času se interpretace výrazů znatelně zrychlila, a nyní rychlostně zaostává za klasickými interprety o desítky (verze 13), nikoliv už ale o stovky procent. Rychlost PL/pgSQL byla většinou bezpředmětná vzhledem k jeho použití pouze pro psaní uložených procedur, kde naprosto jasným úzkým hrdlem je provádění SQL příkazů. Nicméně se PL/pgSQL začal používat i pro některé numericky orientované úlohy (PostGIS), a tam rychlost PL/pgSQL byla omezující.&lt;br /&gt;
&lt;br /&gt;
Víceméně od samotného začátku se používají cache pro prováděcí plány SQL dotazů i výrazů (což fakticky jednoduchý SQL příkaz SELECT). Ve verzi 8.3 se správa cache plánů centralizovala. Od té doby se v PL/pgSQL nepracuje s prováděcími plány přímo, ale skrz pomocný objekt SPIPlanPtr - který se pak dál odkazuje na centrální cache prováděcích plánů (stále platí, že tato cache plánů je per proces - není sdílená). Díky nepřímému odkazu lze odstranit prováděcí plán dotazu z cache (např. po vymazání objektu na kterém prováděcí plán závisel), ale samotný ukazatel v PL/pgSQL zůstává stále platný. Po smazání konkrétního objektu lze odstranit pouze dotčené prováděcí plány a nikoliv všechny. Zavedením externí cache prováděcích plánů se vyřešil problém s neplatnými referencemi na smazané objekty. &lt;br /&gt;
&lt;br /&gt;
Jednou z nejstarších optimalizací byla implementace tzv zjednodušeného vyhodnocování výrazů. Pro některé výrazy, kde se nepracuje přímo s daty v databázi, nemusíme inicializovat celý aparát pro vyhodnocení dotazu, a můžeme rovnou volat interpret výrazů. Stále se používá plancache, díky čemuž nejsou problémy s referencemi například na smazané a znovu vytvořené funkce. U extrémně jednoduchých výrazů byla výrazná režie kontroly platnosti plánů - plán se musí regenerovat pokud dojde k smazání objektu a také pokud dojde k ukončení transakce, kdy se může změnit definice funkce nebo např. po změně search_path. U jednoduchých výrazů tyto kontroly představovaly výraznou režii. Kontrola se prováděla před každým vyhodnocením. Počínaje verzí 13 se režie kontroly redukuje tím, že se definuje nadřazená struktura - resource owner, která sdružuje původně takto kontrolované plány, a přímo v reakci na některé události evidované plány odstraní z cache. Tudíž před spuštěním interpretu výrazů stačí jednoduchá kontrola existence plánu v cache (bez nutnosti ověření validnosti plánu v cache), a pokud plán v cache není, tak se vytvoří.&lt;/div&gt;</summary>
		<author><name>imported&gt;Pavel</name></author>
	</entry>
</feed>