Vlákno názorů k článku PostgreSQL 12 – bude rok 2019 rokem Postgresu? od klokan - Někde jsem četl, že kromě běžného JIT překladu...

Někde jsem četl, že kromě běžného JIT překladu také chtějí využívat GPU?

A obecně si říkám, jestli by pro databázi mělo v principu smysl používat SIMD instrukce jako AVX: možná naivně si představuji, že u operací typu SELECT A WHERE A<B by mohly byt dost efektivní?

Využití GPU pro databáze je spíš pořád výzkum a ještě to bude hodně dlouho mimo upstream - u klasické relační databáze (řádkové) s klasickým executorem to zatím moc smysl nedává, i když lze GPU akcelerovat JOIN a ORDER BY - http://heterodb.github.io/pg-strom/release_note/ . Ve chvíli, kdy Postgres bude mít také sloupcově uložená data a push executor (rozšíření), tak by to smysl mělo. Předpoklad je i podpora in-memory tabulek, tak aby se nepálil čas načítáním dat z disku a rozbalováním z diskového formátu. Za pár let by to ale mohlo být.

Dobry den
Predem dekuji za vyčerpavajici članek.
Zaujala mě ta in-memory:
Chtěl bych se zeptat když už jste to nakousl jak to s tou in-memory vypada a jestli se to bude cca za rok v nějake devel verzi testnout? Použivam u konkurence (funguje to super , ale neni to uplne levne )
A potom jestli postgresSQL má nějaké možnosti řízeně držet v paměti tabulky popř indexy, nebo jejich části ?

Tak teoreticky si můžete in-memory vyzkoušet už nyní - skrze https://pgxn.org/dist/imcs/. Dále existují FDW drivery pro Redis https://github.com/nahanni/rw_redis_fdw, existuje driver pro Elastic. Možná za rok - za dva bude extenze založená na novém api pro custom heaps - integrace inmemory tabulek, pokud bude, bude asi následovat až za podporou column store a push (nebo block) executoru - což může být docela dlouhá cesta - jsou to změny napříč celou databází. Slyšel jsem o experimentech s persistentní RAM https://www.pgcon.org/2018/schedule/events/1154.en.html - celé je to běh na dlouhou trať - spíš tak 3-5 let.

V Postgresu není žádná možnost jak zafixovat objekty v paměti - implementačně by to nebyl asi velký problém, ale nikdo ještě nevymyslel jak vyřešit optimalizaci přidělení do paměti - mohlo by se Vám stát, že vám jakýkoliv dotaz utaví IO, protože nebude mít k dispozici RAM, protože ta bude obsazená zafixovanými objekty, může se stát, že by Vám došla RAM pro zafixované objekty, atd - a do nějakých příliš jednoduchých řešení typu MySQL inmemory tables se nikomu moc nechce. Máte možnost rychle dostat objekty do RAM extenzí pg_prewarn - a pak, když budete mít dost RAM, tak se Vám tam udrží. V případě e-shopů se doporučuje mít velikost RAM 2-3 násobek velikosti db.