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 :-)

XCHAOS: Ach jo. Njn. Proc proste pouzit to co radi google, kdyz je mozne "zasvecene" tlachat o pouzivani gdb, "ostude" MySQL ktera se pry rozbije kdyz se neco nevejde do pameti, pripadne o hloupych adminech kteri resi problemy prikupovanim pameti, coz? Jak u blbejch 8(

XCHAOS: , že cosi, co se projevuje až od určitého množství záznamů, ti většina adminů bude řešit přiobjednáním paměti - ale prdlajs.

XCHAOS: protože se předem dovím, že jsem napsal dotaz, který třeba nejde jednoduše překompilovat, či tak něco - co myslis tim "jednoduse prekompilovat"? Nechces spis rict "dostatecne zoptimalizovat"? To se sazmorejme nedozvis ani v tvem pripade, protoze ta optimalizace zalezi na databazi a tu behem compile time nemas. Takze, co "tak neco"?

REDGUY: jo, REPAIR table pomohlo, to je fakt :-)

XCHAOS: Sorry, ale fakt nechapu co se vlastne snazis rict. Nejdriv placas neco o tom, ze je ostuda kdyz ma mysql problemy kdyz cela tabulka nevejde do pameti i kdyz se se sloupcema nepracuje (wtf, mimochodem), ted najednou rikas ze velikost sloupcu nehraje roli. Co se vlastne snazis rict? Ze to mas rozbity a netusis proc? Zkousel jsi ten repair table, jak jsem psal? Jakej storage engine ma ta tabulka?

ISTEVE: faktem je, že s velikostí paměti vs. tabulky to nejspíš souvisí, protože chyba se začala projevovat až od určitého množství záznamů - a i výsledky které mi našel na tenhle MySQL error Google naznačují to samé - že se to začalo projevovat až po řádově podobném množstvím záznamů (přes 10 000).

a faktem je, že cosi, co se projevuje až od určitého množství záznamů, ti většina adminů bude řešit přiobjednáním paměti (zvlášť pokud vývoj aplikace neprobíhá in-house, což je u opensource/free software velmi běžné, citatation doufám not needed :-)

REDGUY: prospěje mě - protože se předem dovím, že jsem napsal dotaz, který třeba nejde jednoduše překompilovat, či tak něco :-)

jde o to, že nemám rád, když mi něco přestane fungovat za běhu. to se normálně děje sysadminům, ne programátorům.

XCHAOS: V tom pripade doufam ze neurazi, kdyz to budu povazovat za bullshit vycucanej z prstu -- at uz tebou jakozto back story, nebo autorama reseni "prikoupime pamet", nebo (coz povazuju za nejpravdepodobnejsi) si spojujes dve veci ktery spolu nesouvisej.

XCHAOS: "evidentne"? [citation needed], ale ponevadz odmitas dat solidni dukaz, pak nejen ze to neni evidentni, ale jako bonus to smrdi bullshitem

REDGUY: měl jsem tam blbých 10 000 záznamů a snažím se vydedukovat, co je tam naprogramované blbě. Což není snadné a velikost sloupců v tom velkou roli hrát nebude:

mysql> SELECT id FROM guestbook WHERE (UNIX_TIMESTAMP(datum) + 3600*24 < UNIX_TIMESTAMP(NOW()) AND hodnoceni >= 0) ORDER BY id DESC LIMIT 64;ERROR 1030 (HY000): Got error 134 from storage engine

XCHAOS: Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká porad cekame az nam vysvetlis cemu presne ta kompilace prospeje a jak moc.

ISTEVE: no prostě vím o řadě firem, kde by tenhle problém řešili přikoupením RAMěti pro databázový server (reps. přikoupením paměťové kapacity v cloudu) :-) (citation je profesní tajemství, takže nebude)

XCHAOS: u MySQL evidentně hraje roli to, zda se celý obsah tabulky vejde do paměti - Chces rict, ze si myslis ze kdyz mam 10GB tabulku a 1GB pameti, tak s ni MySQL neumi pracovat? Opravdu se snazis rict hole?

REDGUY: ano, skutečně mi to překvapilo. Nicméně potom už neprošel ani ten s nulou, tak to asi byla nějaká zanedbatelná náhoda (šlo prostě o množství výsledků v dotazu, kterých je pro lépe a lépe hodnocené komentáře logicky méně a méně).

Pokud ale dělám jen SELECT id FROM... tak se ta data se kterými dotaz pracuje do paměti bohatě vejdou a dotaz je navíc velice svižný.

Podle mě se to otázky pre-kompilace SQL dotazů docela dotýká - i když jen letmo - protože jak je vidno, tak SQL není tak chytré, jak se snaží předstírat (aspoň MySQL ne)... prostě fakt rád bych zase dělal na kompilovaném projektu, kde některé věci jsou jasné předem a ne až za běhu.