XCHAOS: ale dostat rovnou pointery do paměti - podivej, pokud mas rovnou pointery do pameti, tak se fakt nemusis srat se SQL datovym modelem kde jsi omezenej na hejno tabulek. Kdyz to mas v pameti, tak proc delat nejakou bizarni relaci mezi tabulkama Users, Posts a UserPosts, kdyz muzu proste muzu mit objekt User kterej bude mit pole/list/whatever pointeru na objekty Posts. Proste pouzijes normalni datovy struktury urceny pro praci s datama v pameti.

no nic. čau.

REDGUY: tak z podstaty pre-kompilace tak nějak vyplývá, že v případě modifikace těch tabulek by bylo nutné aplikaci kompilovat znova. fakt mě přijde, že toto jsou tak samozřejmé věci, že o nich prostě nemluvím. (jeden z důvodů, proč chci optimalizovat je, abych mohl SVOJE vlastní aplikace provozovat i bez adminů - protože ti se historicky ukázali jako nejnákladnější a nejnepředvídatelnější položka vůbec...)

co se optimalizace query podle obsahu a nikoliv podle struktury týče - tam samozřejmě kapituluju. (ovšem o tomto typu optimalizace mi např. DESCRIBE u MySQL neříká nic...)

XCHAOS: Nevím, jak tě mohlo napadnout, že ten precompiler by neměl informace o tom, nad kterými sloupci má k dispozici indexy a nad kterými ne - to je přece základ. - coze? Ty v dobe kompilace presne vis, jake indexy bude mit ten program za pul roku k dispozici? Wow, magic. A i kdyby, znamena to, ze pri kazde zmene databaze (treba pridani indexu), ktera u normalniho SQL vubec nevadi, budes muset prekompilovat aplikaci? To zni skvele.

A hlavne, stale ignorujes (nebo proste nechapes) fakt, ze query optimizer bere do uvahy i _obsah_ databaze, ne jenom jeji strukturu. Opravdu jsi takovej vizionar, ze pul roku dopredu znas nejen strukturu, ale i obsah databaze?

DAVIDOWITCH:
DAVIDOWITCH: ... snad alespoň ty bys mohl mít pochopení pro to, že podstatou celé myšlenky bylo netlačit data přes socket, ale dostat rovnou pointery do paměti... tedy eliminovat z procesu tlačení dat přes socket.

protiargumentem bylo, že v éře CPU cache (to je věc, která se začala běžně používat až poté, co já si běžně přestal hrát se strojovým kódem - takže pro mě intuitivní dělení je pořád "paměť vs. disk" ačkoliv dnes je to častěji "cache vs. paměť vs. disk") , nota bene v éře swapování na disk :-) je mi stejně pointer do paměti platnej asi jako kreditní karta k účtu, na kterým vůbec nemusí být peníze. bohužel to asi protiargument bude, tak se soustředím nadále na to, čím tráví PHP tu půl sekundu času...

REDGUY: je asi jednodušší ponechat ti poslední slovo, než snažit ti podesáté něco vysvětlit.

(az doiterujes tu odpoved.. tak pro pripadne zrychleni se vyser na C API a koukni na predkompilovany procedury)

DAVIDOWITCH: jo. ne. totiž v té půlsekundě jsou asi věci jako komunikace s SQL server, protlačení dat socketem a tak.

ale máš pravda - v první fázi budu pracovat s přístupem přes libmysqlclient z C aplikace a uvidím, jak se to bude chovat (oproti PHP). na to lowlevel SQL C API jsem se ptal pouze proto, jestli někdo netuší, zda to existuje - to samozřejmě připouštím, že výrazně přesahuje moje možnosti, něco takového vymyslet.

REDGUY: no bylo by to něco jako ten DESCRIBE .. a tedy samozřejmě, pracovalo by se se strukturou tabulek v době kompilace. Nevím, jak tě mohlo napadnout, že ten precompiler by neměl informace o tom, nad kterými sloupci má k dispozici indexy a nad kterými ne - to je přece základ.

XCHAOS: Takze abych to shrnul, celej dotaz je nemeritelne rychlej, pricemz tusime (podle resi o tom jak se neco nevejde do pameti), ze parsovani asi nebude ani 50% tohohle nemeritelnyho useku, takze bych to uzavrel tim, ze predkompilovavani dotazu je ptakarna a spis by se mel clovek zamerit na optimalizaci databaze/dotazu?

BTW můj typický jednoduchý dotaz do tabulky trvá 0.00 sekund (když se použije KEY a tak). vygenerování PHP stránky (jen samotný běh kódu - bez načtení do browseru) trvá typicky např. 0.56 sekund (ve stránce je použitý stejný SQL dotaz a hodnota se vypisuje dříve, než proběhne odeslání nějakého docela komplexního footeru, apod.). No dobře, je tam pár dalších subqueries - ale všechny trvají zanedbatelnou dobu, jsou do tabulek s mizivým množstvím dat, cacheuju je na úrovni PHP apod.

to beru jako finální argument, proč chci bastlit webové aplikace v Céčku místo v PHP: někde někdo něco prostě implementuje hodně špatně a mě ta zbytečná půl sekunda navíc přijde jako obchodní příležitost.

(co sakra sedíte u compu v neděli? mazejte někam ven)

(pouze jsem chtěl předvést, že i špatný způsob jak řešit problém může vést k velmi zajímavým a plodným výsledkům :-)

ok, končím offtopic vsuvku. a mimochodem, tématem jsou vhodné datové struktury do C aplikací :-) (tak nějak dlouhodobě)

ha, teď to dokonce použvá dva kroky, oba s primary key! :-)

mysql> describe SELECT UNIX_TIMESTAMP(datum) AS unixtime, jmeno, vzkaz, id, hodnoceni, hodnoticich FROM guestbook WHERE id IN (SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0)) ORDER BY id DESC LIMIT 64;
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
| 1 | PRIMARY | guestbook | index | NULL | PRIMARY | 4 | NULL | 11329 | Using where |
| 2 | DEPENDENT SUBQUERY | guestbook | unique_subquery | PRIMARY,hodnoceni | PRIMARY | 4 | func | 1 | Using index; Using where |
+----+--------------------+-----------+-----------------+-------------------+---------+---------+------+-------+--------------------------+
2 rows in set (0.00 sec)

mysql> describe SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC LIMIT 64;
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
| 1 | SIMPLE | guestbook | range | hodnoceni | hodnoceni | 5 | NULL | 10333 | Using where; Using filesort |
+----+-------------+-----------+-------+---------------+-----------+---------+------+-------+-----------------------------+
1 row in set (0.00 sec)

REDGUY: já top BTW vyřešil high-level SW optimalizací, která BTW funguje i teď, a mj. mi dělá filesort nad menším množstvím dat, než simple dotaz :-)

REDGUY: to bylo až asi ve 4. výsledku, tahle rada :-)

REDGUY: tak samozřejmě... jestli se něco vejde do paměti, nebo ne, to během compile-time nevím. nicméně třeba by pomohlo vidět ten vygenerovaný kód, abych viděl, co od toho čekat, nebo tak?

prostě je víc způsobů, jak přemýšlet o nějaké aplikaci - skriptování vs. kompilovaná aplikace, SQL dotazy vs. nativní storage, objektový vs. neobjektový návrh aplikace, apod. - já hledám nějaký nový level, na který se posunout, protože se zatím plácám uprostřed stejného bastlení, jaké probíhá masově všude kolem mě (a představuje masivní plýtvání zdroji, podle mě)

REDGUY: viz upřesňující zmínka o in-house vývoji :-)