Vlákno názorů k článku Novinky v připravovaném PostgreSQL 9.3 od Fr.Holtzmann - v MySQL komunite se objevilo nekolik pristupu, jak...
-
Každý rok 1. dubna někdo přijde s podobným návrhem. Teoreticky by to ale neměl být velký problém - ještě z dob před SQL podporuje Postgres tzv FastCall API (a protokol) a napsat extenzi, která by obalovala INSERT, UPDATE, DELETE je práce tak na dva dny (interní API tam je). Možná ještě méně. Jenomže proč to dělat? Postgres je ACID MGA relační databáze. Key value CAP databáze budou řádově rychlejší - pro jednořádkové INSERT, UPDATE, DELETE, SELECT operace - i kdyby se jednoduše obešlo SQL (většina relačních databází je optimalizovaná pro hromadné operace). Přepsat Postgres pro CAP by znamenalo napsat skoro celou novou databázi, což mi přijde zbytečné, když už tu CAP nebo memory NoSQL databáze jsou.
Technicky to možné je, zatím to nikdo nezkusil. A osobně jsem docela skeptik. U dobře napsaných aplikací má SQL zanedbatelnou režii, a u špatně napsaných by to ničemu moc nepomohlo, bo by se rychle narazilo na limity způsobené podporou ACID. Ale třeba to někdo někdy dá. Může to být i zajímavý test jestli někde v pg není třeba nějaká performance bota.
-
Fr.Holtzmann (neregistrovaný)
diky za links, takze koukam, ze uz se na to dokonce nekdo ptal. Jestli tomu rozumim spravne, tak ta FastPath interface se nedoporucuje a misto toho by se vzala jednoduse SPI s prepared statemensts - to uz jsem zkousel a meril a bohuzel je to stale jeste dost pomale. (proti ndb-engine nebo ads)
Otazka proc to chtit je vlastne jiz nahore zodpovezena neprimo, handlersocket by nevznikl, kdyby to nikdo nepotreboval. U postgresql by se to hodilo, protoze je to proste jedina databaze, ktera je free bez vsech tech ostatnich 'svobod'. Jak psal autor handlersocketu, udelali to proto, ze chteli rychlou interface pro jednotlivy pristup a presto mit moznost odsadit komplikovanou query.
Ale nejak to jit musi, protote alaska-software (vyrobce Xbase++) chce pouzit postresgq jako backend. (aby mohli uz konecne opustit foxpro). No, uvidime :-)
-
Pokud jde opravdu o co nejrychlejší emulaci ISAM engine, tak pak potrebujete obejít protocol a komunikovat s db přímo - což by teoreticky nyní šlo snáze díky background worker processu - a dál už by bylo volání lowend funkcí pro přístip k datům. Potom nejsou potřeba ani PP statements. Pořád si netroufám odhadnout o kolik by tento přístup byl rychlejší - možná výrazně, pokud budete mít data v cache. Reálně by ovšem mělo být hrdlem IO operace.
ČLÁNKY DO MAILU