Új hozzászólás Aktív témák

• #63 lezso6 HÁZIGAZDA lenox #61

  Új Válasz 2014-12-28 21:54:33 #63

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  válasz lenox #61 üzenetére

  Hát persze, nincs benne heterogén rész.

• #19 lezso6 HÁZIGAZDA maross #11

  Új Válasz 2014-12-24 15:09:58 #19

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  válasz maross #11 üzenetére

  CPU-limit. Sok a privát, R6-ban lesz optimalizálva először SQL-ileg. Majd valamikor meg át lesz alakítva az egész privát üzenet tároló struktúra, mert a jelenlegi ennyi privátnál már nem túl optimális.

• #10 lezso6 HÁZIGAZDA dabadab #6

  Új Válasz 2014-12-24 00:22:01 #10

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  válasz dabadab #6 üzenetére

  Bizonyos helyzetekben CPU limit van, pl komplex keresési feltételnél, amikor hiába lassú az IO, a CPU még lassabban ellenőrzi le a sorokat. Ez utóbbira van a PgStrom. Vagy ha pl memóriában egy bazi nagy invertált indexet kell átnyálazni, akkor is CPU limit lehet. Ez meg tipikusan a keresésnél szokott lenni.

• #5 lezso6 HÁZIGAZDA XmoD #4

  Új Válasz 2014-12-23 20:49:54 #5

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  válasz XmoD #4 üzenetére

  Igazából engem nem a GPU része érdekel, hanem az OpenCL, hogy CPU-ra többszálasítsa a feladatokat, amivel sokkal jobb válaszidő lenne elérhető elvileg. Gyakorlatban persze ez kérdéses, mert az OpenCL overhead nem biztos hogy elhanyagolható, így gyanús, hogy csak GPU-n lesz jó, az viszont meg már nincs ingyen.

• #1 lezso6 HÁZIGAZDA

  Új Válasz 2014-12-23 19:33:49 #1

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  lezso6

  HÁZIGAZDA

  Hm, ezt már olvasgattam anno, azt hittem elveszett a CUDÁ-ba az egész, de ezek szerint rámozdultak az OpenCL-re, ami nagyon jó hír. Viszont ennek a seqscan / hash-join / aggregate gyorsításnak én sok értelmét nem látom. Ugyan tényleg bazi lassúak, de elég speciális terület szerintem. Ami ténylegesen hasznos lenne több szállal gyorsítani az talán a GIN index scan. Ez sajnos jelenleg viszonylag lassú, bár pár napja kijött a PostgreSQL 9.4, ami a GIN sebességén nagyot javított, ennek köszönhetően a natív fulltext állítólag már Sphinx teljesítményt nyújt, az új JSONB adattípus meg a MongoDB-nek csap oda. S akkor ennek még egy kis nitró több mag kihasználásával illetve GPU-val...

  Hajrá PostgreSQL! GPU-val gyorsított RIOS-t!

Új hozzászólás Aktív témák