Vlákno názorů k článku
Online webinář zdarma: Co je nového v PostgreSQL 16 od cc - a použití SIMD instrukcí na x86 a ARM. Čti...

a použití SIMD instrukcí na x86 a ARM.

Čti Postgres v r. 2023 už umí použít SSE2 instrukce z roku 2000 :)

Ono pro relační databázi není moc příležitostí jak je využít. I to anoncované použití je mikrooptimalizace, která dává pár procent ve specializovaných best case benchmarcích. To, co můžete urychlit v databázi s řádkovým uložením dat je počítání kontrolních součtů, porovnávání řetězců a operace nad UTF8 kódováním. Kontrolní součty jsou hw akcelerované už delší dobu, porovnání stringů dělají externí knihovny, a teď se optimalizovaly i operace nad UTF8. V relačních databázích se většinou nepracuje s tak dlouhými stringy aby se vám vyplatilo použití SIMD instrukcí. Něco jiného jsou analytické in memory sloupcové databáze jako je např. MonetDB. Ale to jsou databáze absolutně jiného typu než je Postgres. Postgres - optimalizace na kombinaci multi uživatelský SELECT/UPDATE - data jsou primárně na disku, Monet - optimalizace na jednouživatelský SELECT (agregace), data jsou primárně v RAM (a více méně omezená RAM).

Nedalo by se spíš napsat "Postgres má takový overhead, že SIMD nedává smysl"?

Ani ten JIT není teda nic moc, abych řekl pravdu.

SIMD se zavedly pro podporu zpracování obrazu, videa, náročné numerické výpočty, maticové výpočty. Co z toho děláte v relační transakční databázi?

V GoodData jsem viděl, že JIT některé dotazy zrychlovalo o 30% na jedno CPU. JIT v Postgresu aktuálně optimalizuje jen výrazy, takže vám signifikantně pomůže jen tehdy, pokud používáte dlouhé komplexní výrazy - stovky CASE větví atd. V multidimenzionální analýze se takové dotazy objevují. Pokud multidimenzionální analýzu neděláte, tak se s tím nesetkáte. Těch 30% je na jedno CPU, pokud se použije více n CPU, tak je benefit zhruba 30/n %. Podpora JITu zdaleka není hotová - chybí cacheování přeloženého kódu, chybí JIT executoru. Sám JIT má ale dost velký (a někdy patogický overhead).

K tomu JITu bych jen posnul tento link:

https://dev.to/xenatisch/cascade-of-doom-jit-and-how-a-postgres-update-led-to-70-failure-on-a-critical-national-service-3f2a

Já dělal na jiné DB, kde SIMD pomohl hodně, ale byla to úplně jiná architektura. Ono když pro zpracování jednoho řádku se provede 100 volání nějakých pomocných funkcí, tak SIMD opravdu nedává smysl. Ale zpracovat třeba několik řádků současně, pokud to jde, to už smysl dává.

Ještě doplním - režie se implementací optimalizujícího planneru, zajištění perzistence dat a implementace ACIDu má ohromnou režii - jedno jestli je to MySQL, PostgreSQL nebo Oracle nebo MSSQL. Rychlost čtení dat z in memory databáze, která má jednoduchý protokol může být o řád nebo dva řády rychlejší - viz výkon Redisu nebo memcached.