Názor k článku PostgreSQL 10: drsně rozběhnutý slon od Pet - Dakujem Vam za odpoved pan Stěhule, Nad tymi SSD...

Dakujem Vam za odpoved pan Stěhule,
Nad tymi SSD uvazujeme.
Zatial sme v archive implementovali vlastnu cache. Dnes uz je RAM niekde inde ako pred 10 rokmi, takze su zakaznici, kde moze mat aplikacia pristupujuca k datam (archiv) napr 2 alebo 6 GB RAM cache do ktorej sa vmesti poslednych niekolko dni. Takze bezni uzivatelia pozadujuci cerstve data (napr. do grafov za poslednu smenu/24 hodin a pod) ich maju do niekolko ms bez dotazovania databazy. Ostatni si pockaju (nove data idu z cache+starsie cez dotaz do DB).
Taktiez mame "casove rezy" - 'partitioning' ktory si robi samotna aplikacia - 30 dni naplna tabulku a potom urobi dalsiu - a po naplneni ju vieme upratat (cluster table) takze ta fragmentacia starsich dat sa poriesi. (casove rezy su teda funkcne napr. aj na Oracle SE/SEO/SE2 kde partitioning nefunguje z licencnych dovodov).
Pouzivame PgSql na Windows platforme; ked konvertujem databazu z Oracle, zvycajne zapinam NTFS kompresiu na adresari s databazou; kompresny pomer byva spravidla 2:1 (az 2.5:1), cim sa mi velkost dat oproti Oracle plus minus nezvacsi. Na vykone pri zapise kompresia ma vplyv na urovni niekolko % (akurat zalohovanie je pomalsie).
Co je ale pre mna najdolezitejsie: postupne nasadzujeme PgSql na viacerych zakaznikov a aj ked ma nizsi vykon ako Oracle, tak POSTACUJE. Tj. existujuce zelezo to utiahne (o novom ani nehovorim), takze nic z toho, co spominam, nie je taky problem, aby sme Postgres nepouzili.
Dakujem Vam aj za tu TimescaleDB, urcite vyzera zaujimavo a vyskusame ju ..