Byl vydán Fedora Asahi Remix 40, tj. linuxová distribuce pro Apple Silicon vycházející z Fedora Linuxu 40.
Představena byla služba Raspberry Pi Connect usnadňující vzdálený grafický přístup k vašim Raspberry Pi z webového prohlížeče. Odkudkoli. Zdarma. Zatím v beta verzi. Detaily v dokumentaci.
Byla vydána verze R14.1.2 desktopového prostředí Trinity Desktop Environment (TDE, fork KDE 3.5). Přehled novinek v poznámkách k vydání, podrobnosti v seznamu změn.
Dnešním dnem lze již také v Česku nakupovat na Google Store (telefony a sluchátka Google Pixel).
Apple představil (keynote) iPad Pro s čipem Apple M4, předělaný iPad Air ve dvou velikostech a nový Apple Pencil Pro.
Richard Biener oznámil vydání verze 14.1 (14.1.0) kolekce kompilátorů pro různé programovací jazyky GCC (GNU Compiler Collection). Jedná se o první stabilní verzi řady 14. Přehled změn, nových vlastností a oprav a aktualizovaná dokumentace na stránkách projektu. Některé zdrojové kódy, které bylo možné přeložit s předchozími verzemi GCC, bude nutné upravit.
Free Software Foundation zveřejnila ocenění Free Software Awards za rok 2023. Vybráni byli Bruno Haible za dlouhodobé příspěvky a správu knihovny Gnulib, nováček Nick Logozzo za front-end Parabolic pro yt-dlp a tým Mission logiciels libres francouzského státu za nasazování svobodného softwaru do praxe.
Před 10 lety Microsoft dokončil akvizici divize mobilních telefonů společnosti Nokia a pod značkou Microsoft Mobile ji zanedlouho pohřbil.
Fedora 40 release party v Praze proběhne v pátek 17. května od 18:30 v prostorách společnosti Etnetera Core na adrese Jankovcova 1037/49, Praha 7. Součástí bude program kratších přednášek o novinkách ve Fedoře.
Stack Overflow se dohodl s OpenAI o zpřístupnění obsahu Stack Overflow pro vylepšení OpenAI AI modelů.
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: