XCHAOS: A me jednou neco jinyho spadlo na segfault! Hruuuuza!
XCHAOS: Ano, resit zivotnost SW v desitkach let v prostredi/obdobi, kdy po deseti letech mas problem sehnat HW na kterym to muze bezet mi prijde absolutne mimo. Neco jinyho by bylo, kdyby si byl i vyrobce dotycnyho HW, tak by to davalo smysl.

XCHAOS: Nemam. Pokud mas data natolik jednoduchy ze je muzes mit ve vlastni pameti ve vlastnim procesu, nemas pouzivat SQL.
Pokud je nemas natolik jednoduchy, tak si ten pointer nevymyslis.
Mne to cim dal tim vic zni jako ze bud pouzivat MySQL na neco na co to je zbytecny, nebo nemas predstavu jak vypada uvnitr databaze (a tudiz si to stylem sobe vlastnim predstavujes jak hurvinek valku).

XCHAOS: fakt mě přijde, že toto jsou tak samozřejmé věci, že o nich prostě nemluvím. - me spis prijde ze o tom nemluvis proto, ze to je problem 8))

tam samozřejmě kapituluju - no slava.

ovšem o tomto typu optimalizace mi např. DESCRIBE u MySQL neříká nic - jak, nerika? Rika. Tedy, nevim jestli MySQL pri optimalizaci bere do uvahy velikosti a obsahy tabulek, ale pokud ano, tak vysledek DESCRIBE ti rika, jak bude dotaz vypadat pro AKTUALNI data. Neni duvod proc by ti rikal, jak by se dotaz provadel kdyby v tabulkach byly uplne jiny data.

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)