Názory k článku Rozšiřování PostgreSQL v C - Rozhraní SPI

zajimavy clanek, ale je otazka, co vlastne plyne
pro psani API k postgresu z toho, ze python je
pomalej (coz samo osobe nepusobi nijak prekvapive),
rekneme tedy, ze je to ilustracni priklad, ktery
ukazuje, ze ruzne veci se daji merit a porovnavat :).

Porovnavam neporovnatelne, vim. Spis mi slo o prokazani, ze se vyplati API v PostgreSQL pouzivat. Listbox v Pythonu sestavite jednoduse v mziku. Totez v PostgreSQL via API tak cca za 20 az 30 minut, kdyz vite o co jde a netrapite se s chybama. Coz ja jsem se trapil :->. Setkal jsem se s nazorem, ze se nevyplati Python pouzivat, protoze je pomaly. Python je pomaly, to je pravda, ale kdyz rozumne vyuziju prostredky, ktere mam k dispozici (PostgreSQL) nemusi mi to vadit. To jestli reseni skrze API je 28x nebo 10x rychlejsi nez reseni v Pythonu vubec neni dulezite. Proste je to jen inspirace pro lidi, kteri vyvijeji v Pythonu.

"Abych urychlil provádění funkce, nealokuji paměť při každém přidání řetězce, ale po blocích - stránkách, jejichž velikost si sami určíme."

Presne to same dela memory managment PG. Znamena to, ze delate blok v bloku a managment nad managmentem. Podle mne tim neziskate velkou vykonstni vyhodu (pokud ano tak je mmgr v PG spatny -- cemuz neverim:-)

Vlastně vůbec netuším, jestli je podobná bloková alokace nutná a jestli se vyplatí. Patrně se vyplatí, protože se vyhýbám reallokaci paměti při každém přidání řetězce. Nakolik, nevím. Na druhou stranu zaberu víc paměti než je nutné.

Rozhodně jsem neobcházel mm PG. Prostě jen takhle řeším spojování většího počtu kratších řetězců, aniž bych použil vázaný seznam. Stejně bych to dělal v "klasickém" prostředí.