Po 9 týdnech vývoje od vydání Linuxu 6.15 oznámil Linus Torvalds vydání Linuxu 6.16. Přehled novinek a vylepšení na LWN.net: první a druhá polovina začleňovacího okna a Linux Kernel Newbies.
Americký výrobce čipů Intel propustí 15 procent zaměstnanců (en), do konce roku by jich v podniku mělo pracovat zhruba 75.000. Firma se potýká s výrobními problémy a opouští také miliardový plán na výstavbu továrny v Německu a Polsku.
MDN (Wikipedie), dnes MDN Web Docs, původně Mozilla Developer Network, slaví 20 let. V říjnu 2004 byl ukončen provoz serveru Netscape DevEdge, který byl hlavním zdrojem dokumentace k webovým prohlížečům Netscape a k webovým technologiím obecně. Mozille se po jednáních s AOL povedlo dokumenty z Netscape DevEdge zachránit a 23. července 2005 byl spuštěn MDC (Mozilla Developer Center). Ten byl v roce 2010 přejmenován na MDN.
Wayback byl vydán ve verzi 0.1. Wayback je "tak akorát Waylandu, aby fungoval Xwayland". Jedná se o kompatibilní vrstvu umožňující běh plnohodnotných X11 desktopových prostředí s využitím komponent z Waylandu. Cílem je nakonec nahradit klasický server X.Org, a tím snížit zátěž údržby aplikací X11.
Byla vydána nová verze 6.18 živé linuxové distribuce Tails (The Amnesic Incognito Live System), jež klade důraz na ochranu soukromí uživatelů a anonymitu. Nově se lze k síti Tor připojit pomocí mostu WebTunnel. Tor Browser byl povýšen na verzi 14.5.5. Thunderbird na verzi 128.12.0. Další změny v příslušném seznamu.
Meta představila prototyp náramku, který snímá elektrickou aktivity svalů (povrchová elektromyografie, EMG) a umožňuje jemnými gesty ruky a prstů ovládat počítač nebo různá zařízení. Získané datové sady emg2qwerty a emg2pose jsou open source.
Byla vydána (𝕏) nová verze 25.7 open source firewallové a routovací platformy OPNsense (Wikipedie). Jedná se o fork pfSense postavený na FreeBSD. Kódový název OPNsense 25.7 je Visionary Viper. Přehled novinek v příspěvku na fóru.
Před 40 lety, 23. července 1985, společnost Commodore představila první počítač Amiga. Jednalo se o počítač "Amiga od Commodore", jenž byl později pojmenován Amiga 1000. Mělo se jednat o přímou konkurenci počítače Apple Macintosh uvedeného na trh v lednu 1984.
T‑Mobile USA ve spolupráci se Starlinkem spustil službu T-Satellite. Uživatelé služby mohou v odlehlých oblastech bez mobilního signálu aktuálně využívat satelitní síť s více než 650 satelity pro posílání a příjem zpráv, sdílení polohy, posílání zpráv na 911 a příjem upozornění, posílání obrázků a krátkých hlasových zpráv pomocí aplikace Zprávy Google. V plánu jsou také satelitní data.
Společnost Proxmox Server Solutions stojící za virtualizační platformou Proxmox Virtual Environment věnovala 10 000 eur nadaci The Perl and Raku Foundation (TPRF).
Ahoj, toto mi připadá poněkud zvláštní:
db_pokus=> create table dummy( number int primary key ); CREATE TABLE db_pokus=> set enable_seqscan = false; SET db_pokus=> explain select number from dummy where number = 5; QUERY PLAN ------------------------------------------------------------------------ Index Scan using dummy_pkey on dummy (cost=0.00..8.27 rows=1 width=4) Index Cond: (number = 5) (2 rows) db_pokus=> explain select 5 in ( select number from dummy ); QUERY PLAN -------------------------------------------------------------------------------- Result (cost=100000040.00..100000040.01 rows=1 width=0) SubPlan -> Seq Scan on dummy (cost=100000000.00..100000034.00 rows=2400 width=4) (3 rows)
Fakt nechápu, proč se u druhého dotazu taky nepoužije index. Abych řekl pravdu, myslel jsem, že ten optimalizátor bude o něco chytřejší. Netušíte někdo, jak by tohle řešil například Oracle? Když se zeptám, zda existuje primární klíč dané hodnoty, je přece jasné, že se k tomu dá použít index. Nebo mi něco podstatného uniká?
aby výstup z explainu byl co k čemu, je potřeba aktualizovat statistiky. Příkaz EXPLAIN.
Na tomto případě statistiky nic nezmění. Pokud zakážu seqscan a optimalizátor ho i přesto použije, znamená to, že nenašel žádnou jinou možnost provedení dotazu. Tady ovšem jiná možnost zjevně existuje...
Optimalizátor má hlavně problém s tím, že konstanta je na levé straně oparátoru IN. To je hodně netypické - osobně jsem nikdy podobný dotaz neviděl v praxi ani nic tomu podobného. V tomto kontextu se operátor IN nepoužívá. Mnohem typičtější zápis je:
SELECT EXISTS(SELECT number FROM dummy WHERE number = 5)
Ano, tohle používá index a je to bez problémů. Jen mi to připadá divné. Včem je (z pohledu optimalizátoru) tak nepřekonatelný rozdíl mezi IN
a EXISTS
?
Jasně, to s EXISTS
je prostě vyhodnocení poddotazu, který naprosto zjevně používá index. Následuje test, zda se něco našlo. Zato verze s IN
tak nějak naznačuje „napřed vem úplně všechno a pak něco porovnej“. Ale v takto triviálním případě by přece měl optimalizáotr vědět, co z vnořeného dotazu vlastně potřebuje.
Důležitým faktem je, že když SELECT
uvnitř EXISTS
upravím tak, aby zahrnoval úplně všechny položky tabulky, dotaz je pořád stejně rychlý a zjevně se nikde neprochází celá tabulka. Ten případ s IN
je nějaký zakletý.
enable_seqscan
je len odporucanie pre optimalizator, presne ako je napisane v dokumentacii.
Ne, to není doporučení a dokumentace nic takového neříká. To je podmíněný zákaz. Použití seqscan je tím zakázáno v takových případech, kdy existuje jakýkoliv jiný možný plán.
Plánovač tedy vyhodnotil situaci (nesprávně) tak, že není jiná možnost než průchod celou tabulkou. Přitom je naprosto zjevné, že jiná možnost tu existuje.
U automaticky generovaného SQL kódu se takové věci často nedají ovlivnit.
Proto je také automatické generování kódu pitomost na n-tou.
Možná, ale já o tom bohužel nerozhoduji.
Ano, zejméně v případech, kdy člověk programuje například SQL terminál, že ano.
No dobře, já sice nedělám SQL terminál, ale tou poznámkou jsem chtěl naznačit, že v některých situacích prostě není zbytí. Jinými slovy, dostanu nějaký SQL kód zvenčí a něco s ním mám dělat.
No, když tu optimalizaci nezvládli autoři databáze, kteří tu problematiku znají stokrát lépe než já, pak asi není šance, že bych dokázal vytvořit nějaký optimalizátor. (Upřímně řečeno, měl bych vážný problém i s parserem.)
Enables or disables the query planner's use of sequential scan plan types. It's not possible to suppress sequential scans entirely, but turning this variable off discourages the planner from using one if there are other methods available. The default is on.Takze tato volba odradza planovac od volby planu s full scan-om, ale nezakazuje ho bezpodmienecne. Takze na spravani planovaca nie je nic, co by odporovalo dokumentacii. Navyse, na full scan-e nie je nic zle.
Tak prosím, tohle je další průšvih:
db_pokus=> explain select * from dummy where number <= all ( select number from dummy ); QUERY PLAN ---------------------------------------------------------------------------------------- Seq Scan on dummy (cost=200006967.93..1265785714.93 rows=180224 width=8) Filter: (subplan) SubPlan -> Materialize (cost=100006967.93..100011980.41 rows=360448 width=8) -> Seq Scan on dummy (cost=100000000.00..100005199.48 rows=360448 width=8) (5 rows)
S indexem by něco takového byla prostě hračka, otázka zlomku vteřiny. Vložil jsem do tabluky dummy cca 360000 záznamů a pak jsem spustil ten dotaz. To bylo před deseti minutami a dotaz stále běží. Tedy se opravdu jedná o závažný problém plánovače.
Tohle je ale zklamání na celé čáře. K čemu je vlastně dobrý DBMS, který není schopen získat minimální prvek z indexu v logaritmickém čase??? Jasně, není tak zle, select min( number ) from dummy;
je to, co ve skutečnosti chci. To funguje správně a efektivně.
Ale jak už jsem tu jednou psal: U automaticky generovaného SQL kódu prostě někdy vznikne ta výše uvedená ošklivá věc, která v podstatě pošle celou aplikaci do háje už na relativně malých datech.
Čím to může být?
Tohle je ale fakt divné. Nemáte náhodou někdo přístup k Oracle? Zajímalo by mě, jak by EXPLAIN
dopadl tam.
Aha, tak teď jsem se pěkně sekl, protože ta agregační funkce vůbec nedělá totéž. Ten správný a efektivně fungující dotaz vypadá takto:
select * from dummy where number = ( select min( number ) from dummy );
A dotaz, který vede k apokalypse, vypadá takto:
select * from dummy where number <= all ( select number from dummy );
To první si optimalizátor přebere správně a funguje to efektivně, přestože je tam poddotaz. To druhé dělá (aspoň dofám) totéž, ale ještě nikdy jsem neměl trpělivost čekat, až to doběhne do konce. Tak se zdá, že PostgreSQL má problém s operacemi typu in
, not in
, all
a any
.
Ten první dotaz postgres dokáže optimalizovat - optimalizuje se min nebo max. Ten druhý nikoliv - prostě dělá, to co mu přikazujete - porovnává záznam s každou řádkou. Bohužel pg nepoužívá informaci o tom, že sloupec je nebo není PK. Tudíž bez znalosti faktu, že number nesmí být NULL tyto dotazy nejsou totožné.
<=
).
Čím to může být?Pravděpodobně nemáte zapnutou funkci „převod blbých SQL dotazů na takové, které se normálně používají“. Nejspíš si pletete optimalizátor prováděcího plánu dotazu s optimalizátorem dotazu. To druhé asi budete muset napsat sám do toho kódu, který tyhle podivné dotazy generuje.
Tiskni
Sdílej: