Byla vydána (𝕏) nová major verze 17 softwarového nástroje s webovým rozhraním umožňujícího spolupráci na zdrojových kódech GitLab (Wikipedie). Představení nových vlastností i s náhledy a videi v oficiálním oznámení.
Sovereign Tech Fund, tj. program financování otevřeného softwaru německým ministerstvem hospodářství a ochrany klimatu, podpoří vývoj FFmpeg částkou 157 580 eur. V listopadu loňského roku podpořil GNOME částkou 1 milion eur.
24. září 2024 budou zveřejněny zdrojové kódy přehrávače Winamp.
Google Chrome 125 byl prohlášen za stabilní. Nejnovější stabilní verze 125.0.6422.60 přináší řadu oprav a vylepšení (YouTube). Podrobný přehled v poznámkách k vydání. Opraveno bylo 9 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Textový editor Neovim byl vydán ve verzi 0.10 (𝕏). Přehled novinek v příspěvku na blogu a v poznámkách k vydání.
Byla vydána nová verze 6.3 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Přehled změn v příslušném seznamu. Tor Browser byl povýšen na verzi 13.0.15.
Dnes ve 12:00 byla spuštěna první aukce domén .CZ. Zatím největší zájem je o dro.cz, kachnicka.cz, octavie.cz, uvycepu.cz a vnady.cz [𝕏].
JackTrip byl vydán ve verzi 2.3.0. Jedná se o multiplatformní open source software umožňující hudebníkům z různých částí světa společné hraní. JackTrip lze instalovat také z Flathubu.
Patnáctý ročník ne-konference jOpenSpace se koná 4. – 6. října 2024 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytváří všichni účastníci, se skládá z desetiminutových
… více »Program pro generování 3D lidských postav MakeHuman (Wikipedie, GitHub) byl vydán ve verzi 1.3.0. Hlavní novinkou je výběr tvaru těla (body shapes).
SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda FROM tab1 A, tab2 B, tab3 C WHERE A.top_id = '8930440' AND A.id=B.id AND A.id=C.id AND B.popistyp_id=11 AND (B.language='sk' OR B.language='en') GROUP BY A.id ORDER BY B.language='sk' DESCA.id, B.id a C.id je index, taktiež A.top_id je index, B.language je index a A.top_id je index. B.popis typ je text. B.popistyp_id nie je index, keďže mohutnosť je len 12, ale skúsil som dať aj index, no výsledok je rovnaký. tab2 má okolo 3 mil. záznamov Vykonanie dotazu trvá prvý krát niekoľko sekúnd, potom už ide rýchlo, čiže druhý, tretí atď to už nabehne okamžite. Ak ho však zadám po polhodine, zase prvý krát to trvá veľmi dlho, potom to už ide rýchlo. Neviete prosím poradiť, ako by som to mohol zrýchliť? A čo je vlastne príčinou toho, že prvý krát to ide pomaly a potom už rýchlo? Vopred ďakujem za info.
EXPLAIN SELECT ...
- to by Ti malo napovedať, či sa naozaj používajú indexy tam kde sa majú, alebo či ich treba vytvoriť / zmeniť / analyzovať (príkaz ANALYZE
). Takto od pása by som ale tipoval, že pri prvom selecte sa to načítava z disku, preto to trvá dlhšie. Pri ďalších selectoch to potom už je v cache a ide to rádovo rýchlejšie. Ak sa to chvíľu nepoužíva, tak cache sa naplní inými vecami a zase sa to spomalí. Pomôže pridať do stroja viac RAM, ale ak sa jedná o naozaj veľkú databázu, tak potom už len optimalizovať aplikáciu.
id select_type table type possible_keys key key_len ref rows Extra 1 SIMPLE A ref top_id, id top_id 4 const 636 Using temporary; Using filesort 1 SIMPLE C ref id id 4 test.A._id 1 1 SIMPLE B ref id,language id 4 test.A._id 35 Using whereTakže v A tabulke mám použiť spoločný index pre top_id a id? Ja používam index pre top_id a id na každé samostatne.
WHERE
) na velkých datech (statisíce až miliony řádku v několika tabulkách) bylo docela o dost pomalejší než použití klausule JOIN
a potvrdilo se to i na M$SQL(už ale nevím verzi) i když tam byl rozdíl výrazně nižší.WHERE
se vytvoří data na vše a pak se omezují a při JOINování dochází k postupné redukci dat, tudíž to nemá takové paměťové nároky.SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda FROM tab3 AS C LEFT JOIN tab1 AS A ON A.id=C.id AND A.top_id = '8930440' LEFT JOIN tab2 AS B ON B.id=C.id AND B.popistyp_id=11 WHERE (B.language='sk' OR B.language='en') GROUP BY A.id ORDER BY B.language='sk' DESC
CREATE TABLE `tab3` ( `id` int(16) NOT NULL default '0', `url` varchar(255) default NULL, KEY `id` (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `tab2` ( `popis` text, `popistyp_id` int(6) NOT NULL default '0', `id` int(16) NOT NULL default '0', `language` char(2) default NULL, KEY `id` (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
CREATE TABLE `tab1` ( `adresa` varchar(255) default NULL, `top_id` int(16) NOT NULL default '0', `trieda` char(2) default NULL, `id` int(16) NOT NULL default '0', `name` varchar(255) default NULL, KEY `top_id` (`top_id`), KEY `id` (`id`), KEY `name` (`name`) ) ENGINE=MyISAM DEFAULT CHARSET=utf8;
UNIQUE
či PRIMARY
ORDER BY
, má být opravdu na pravdivostní hodnotu ?, dal bych tam jen ORDER BY B.language DESC
nebo ORDER BY B.language ASC
Takže asi takto:SELECT DISTINCT A.name, A.id, B.popis, C.url, A.adresa, A.trieda FROM (SELECT * FROM tab1 WHERE top_id = '8930440') AS A INNER JOIN tab2 AS B ON A.id = B.id AND B.popistyp_id =11 AND B.language IN ('sk', 'en') INNER JOIN tab3 AS C ON A.id = C.id ORDER BY B.language DESCČekal bych vyšší výkon ale nevím (no a pak ještě doladit indexi podle
EXPLAIN
).
DISTINCT
navíc.
SELECT DISTINCT A.name, A.id, B.popis, C.url, A.adresa, A.trieda FROM (SELECT DISTINCT name, id, adresa, trieda FROM tab1 WHERE top_id = '8930440') AS A INNER JOIN tab2 AS B ON A.id = B.id AND B.popistyp_id =11 AND B.language IN ('sk', 'en') INNER JOIN tab3 AS C ON A.id = C.id ORDER BY B.language DESC
SELECT A.name, A.id, B.popis, C.url, A.adresa, A.trieda FROM tab1 A JOIN tab2 B ON B.id = A.id JOIN tab3 C ON C.id = A.id WHERE A.top_id = 8930440 AND B.popistyp_id=11 --AND (B.language='sk' OR B.language='en') --hezci a jednoduseji modifikovatelna je podle me klauzule in AND B.language IN ('sk', 'en') GROUP BY A.id ORDER BY B.language='sk' DESCJestli je klauzule join rychlejsi nez spojeni omezene v klauzuli where se rika, ze by to melo byt vykonove stejne (resp. parser by to mel chapat jako stejny vyraz) a jestli ne, tak se jedna o bug. Nicmene joiny jsou pro spoustu lidi prehlednejsi a v pripade jejich pouziti te syntakticka kontrola nepusti pres opomenute vyjadreni relace...
INNER JOIN
to tak bude. S provádením LEFT a RIGHT JOINU, už to ale bude jinak (nehledě na to že LEF a RIGHT mohou mít na některých enginech rozdílný výkon).
Pozn. na PostrgeSql, jsem četl, že rychlost přes WHERE a JOIN je za ideálních podmínek identická, což už samo o sobě vzbuzuje oprávněnou pochybnost a nutí to aspoň zkusit (bohužel to teď nemohu najít, abych dal odkaz).ORDER BY language15 rows in set (11.39 sec), bez ORDER BY je to (0.39 sec) Potrebujem to však nutne vyriešiť, aby najprv radilo vysledky s language='sk' a až potom výsledky s language='en'. Rozmyšlam vytvoriť tab4 v podstate identickú s tab1 v počte riadkov so stĺpcami 'id' a 'sk', kde by bolo 'sk' buď 1, alebo 0, podľa toho či obsahuje language='sk' a potom dať ORDER BY tab4.sk, možno to bude radiť rýchlejšie.
language
? Potom byt mozno vedela databaza sekvencne citat zaznamy z toho indexu, namiesto citania vsetkych a nasledneho triedenia. To je totiz uzitocny side-effect indexu, ze udaje v jeho listoch su zoradene. Takze ak treba ORDER BY
, staci ist sekvencne podla indexu a testovat splnenie WHERE
; vsetko sa ale da urobit streamovo. A ked sa k tomu pridaju selektivne indexy z PostgreSQL alebo FBI z Oracle, staci dobry index a netreba overovat ani to WHERE
.
Ak sa skutocne jedna iba o pevne dany pocet jazykov, nie je mozne to vyriesit "inziniersky"? T.j. spustit dva selecty za sebou, kazdy pre jeden jazyk, a resultsety si spojit az v aplikacii?
Tiskni Sdílej: