Alyssa Rosenzweig se v příspěvku na svém blogu Vulkan 1.3 na M1 za 1 měsíc rozepsala o novém Vulkan 1.3 ovladači Honeykrisp pro Apple M1 splňujícím specifikaci Khronosu. Vychází z ovladače NVK pro GPU od Nvidie. V plánu je dále rozchodit DXVK a vkd3d-proton a tím pádem Direct3D, aby na Apple M1 s Asahi Linuxem běžely hry pro Microsoft Windows.
Byla vydána (𝕏) květnová aktualizace aneb nová verze 1.90 editoru zdrojových kódů Visual Studio Code (Wikipedie). Přehled novinek i s náhledy a animovanými gify v poznámkách k vydání. Ve verzi 1.90 vyjde také VSCodium, tj. komunitní sestavení Visual Studia Code bez telemetrie a licenčních podmínek Microsoftu.
Byla vydána (Mastodon, 𝕏) nová verze 2024.2 linuxové distribuce navržené pro digitální forenzní analýzu a penetrační testování Kali Linux (Wikipedie). Přehled novinek se seznamem nových nástrojů v oficiálním oznámení.
Počítačová hra Tetris slaví 40 let. Alexej Pažitnov dokončil první hratelnou verzi 6. června 1984. Mezitím vznikla celá řada variant. Například Peklo nebo Nebe. Loni měl premiéru film Tetris.
MicroPython (Wikipedie), tj. implementace Pythonu 3 optimalizovaná pro jednočipové počítače, byl vydán ve verzi 1.23.0. V přehledu novinek je vypíchnuta podpora dynamických USB zařízení nebo nové moduly openamp, tls a vfs.
Canonical vydal Ubuntu Core 24. Představení na YouTube. Nová verze Ubuntu Core vychází z Ubuntu 24.04 LTS a podporována bude 12 let. Ubuntu Core je určeno pro IoT (internet věcí) a vestavěné systémy.
Databáze DuckDB (Wikipedie) dospěla po 6 letech do verze 1.0.0.
Intel na veletrhu Computex 2024 představil (YouTube) mimo jiné procesory Lunar Lake a Xeon 6.
Na blogu Raspberry Pi byl představen Raspberry Pi AI Kit určený vlastníkům Raspberry Pi 5, kteří na něm chtějí experimentovat se světem neuronových sítí, umělé inteligence a strojového učení. Jedná se o spolupráci se společností Hailo. Cena AI Kitu je 70 dolarů.
Byla vydána nová verze 14.1 svobodného unixového operačního systému FreeBSD. Podrobný přehled novinek v poznámkách k vydání.
Řešení dotazu:
UNIQUE INDEX
bud na (symbol, "datetime")
alebo ("datetime", symbol)
- poradie by som volil podla velkosti time spanu v selecte a tiez variability symbolov v tabulke. EXPLAIN
konkretnej query na konkretnych datach napovie.(smallint primary key, varchar(10) not null)
a previazanie cez cudzi kluc.double precision
by som pouzil numeric.
Vykonanie dotazu by mozno zrychlilo vyclenenie symbolov do inej tabulky, napr. (smallint primary key, varchar(10) not null)
a previazanie cez cudzi kluc
Jak to?
Protože SMALLINT se indexuje lépe, než VARCHAR(10).---
priklady pre pgsql (stale nepozname cielovu DB):Ano, asi se lépe indexuje, ale vyhledávání je pak už stejně rychlé, ne?smallint je fixed-size a ma len 2 bajty (a dovoluje pass-by-value), teda je efektivnejsi pri spracovani a indexovani, jednoducho nema overhead, ktorym "trpi" varlena; smallint je mensi, takze sa zmensi velkost riadku a teda sa ich viac zmesti na stranku, takze sa zmensuje IO;
Čas Symbol 2016-05-24 17:15:59.030 A 2016-05-24 17:15:59.035 A 2016-05-24 17:15:59.123 ATo mohou být tři unikátní záznamy, mohou to být tři „duplicitní“ záznamy, nebo dva duplicitní záznamy a jeden unikátní. Záleží na tom, s jakou přesností čas rozlišujete. Když MP tvrdí, že ta kombinace musí být unikátní, chápu to tak, že to tak je z povahy okolního světa, že ta data prostě takto unikátně vznikají. Pak ale potřebuje vědět, jakou přesnost mají ta reálná data, a stejnou přesnost pak nastavit i v databázi. Také to ale může znamenat, že na vstupu mohou být duplicitní záznamy, a splnění podmínky „musí být unikátní“ se musí zařídit až při vkládání dat do databáze (třeba způsobem, že první nebo poslední vyhrává).
Zatial to nevidim ako "cestu do pekel", ale mozno na peknom pekelnom priklade by to bolo zjavnejsie.Když budete mít na vstupu údaje s přesností na desetinu sekundy, a sloupec bude s přesností na sekundy, můžete na vstupu získat duplicitní údaje. Do databáze je nezapíšete a o data přijdete. Když budete mít na vstupu data s přesností na sekundy a ukládat je budete s přesností na milisekundy, a budete potřebovat třeba 5 minut starý záznam, vezmete aktuální čas, odečtete od něj 5 minut a výsledný údaj budete hledat v databázi. A nenajdete nic, protože hledaná čas bude mít na místě milisekund nejspíš nějaké nenulové číslo, jenže v databázi budou samé nuly.
Když budete mít na vstupu data s přesností na sekundy a ukládat je budete s přesností na milisekundy, a budete potřebovat třeba 5 minut starý záznam, vezmete aktuální čas, odečtete od něj 5 minut a výsledný údaj budete hledat v databázi. A nenajdete nic, protože hledaná čas bude mít na místě milisekund nejspíš nějaké nenulové číslo, jenže v databázi budou samé nuly.
Nebo s tím budu počítat a vezmu poslední záznam před daným časem, poslední záznam po něm nebo interpolaci. Nebo ta tabulka může být jen mezistupněm pro generování kumulovaných dat. Nejde naslepo tvrdit, že něco je špatně, pokud nevíte, k čemu ta data slouží a jak se s nimi pracuje.
timestamp without time zone not null
a u toho komentář, že to musí být unikátní, rovnou se ptám, při jaké přesnosti to má být unikátní. Je možné, že to autor ví, ale pak je vhodné to doplnit i do té definice, čímž se těm otázkám předejde.
Tiskni Sdílej: