Byl vydán Nextcloud Hub 8. Představení novinek tohoto open source cloudového řešení také na YouTube. Vypíchnout lze Nextcloud AI Assistant 2.0.
Vyšlo Pharo 12.0, programovací jazyk a vývojové prostředí s řadou pokročilých vlastností. Krom tradiční nadílky oprav přináší nový systém správy ladících bodů, nový způsob definice tříd, prostor pro objekty, které nemusí procházet GC a mnoho dalšího.
Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
update tb1
set cosi = neco_jinyho
from
(
select
tb1.id,
agregacni_fce(kousicky) neco jinyho
from tI join tII
on tb1.id = tII.id
group by tb1.id
)dta
where tb1.id = dta.id
(snad sem nic nevynechal)for i in 1..(select count(*)/500 from tbl) loop
update tbl1
........ where ctid between i*500 and (i+1) * 500;
end loop;
bude tohle delat to co potrebuju
Zkus tohle:update tb1 set cosi = neco_jinyho from ( select tb1.id, agregacni_fce(kousicky) neco jinyho from tI join tII on tb1.id = tII.id group by tb1.id )dta where tb1.id = dta.id
UPDATE tb1 SET tb1.cosi = (SELECT AGG(...) AS neco_jinyho FROM tii INNER JOIN ti ON (tii.id = ti.ref_id) -- uprav si Join Condition WHERE tii.id = tb1.id GROUP BY tii.id) WHERE EXISTS (SELECT 1 FROM tii INNER JOIN ti ON (tii.id = ti.ref_id) -- viz výše WHERE tii.id = tb1.id) /Tohle prostě musí fungovat. Takovýhle dotazy pouštím obden nad miliony záznamy. Ta
GROUP BY
klauzule tam vpodstatě být nemusí, protože v SELECT
klauzuli je jen ta agregačka.
Dotaz zupdatuje sloupek COSI
výpočtem nějaký agregačky pro všechny záznamy tabulky TB1
, pro které existují odpovídající záznamy ve spojení tabulek TI
a TII
.
Rozdělení na více dotazů moc nedoporučuji. Dělá to jen problémy.
Podle toho, co jsem z tvého příkladu pochopil, omezuješ množinu TII
množinou TI
. Jinými slovy, v tabulce TII
máš víc záznamů, které nechceš zahrnout do agregačky. V tom případě doporučuji udělat dočasnou tabulku:CREATE TABLE tmp_data AS SELECT tii.id AS tii_id, "další", "sloupce", "pro", "agregačku" FROM tii INNER JOIN ti ON (tii.id = ti.ref_id) -- uprav si Join Condition / CREATE INDEX idx_tmpdata ON tmp_data (tii_id) /a vypočítat tuto agregačku z této tabule. V případě, že tabulka
TII
obsahuje více nerelevantních záznamů než tabulka TB1
, můžeš tyto záznamy též odstranit například dalším INNER JOIN
em. Ten index může být klidně složený. Databázi pak bude stačit probrousit index a s přístupem do vlastní tabule nebude ztrácet čas.
Když i tohle bude málo, pak si z týhle tabule předpočítej i tu agregačku a to už musí fungovat i kdybys nechtěl.
Když sem nahraješ nějaký rozumný demo na hraní, možná ti i někdo pomůže. Takhle nevíme, jestli je ten tvůj dotaz špatně v reálu, nebo si jen nezvládnul obfuskaci.
update hrany
set geometrie = geom from
(select id_hrany, aggrfce(geom_body)
from spojeni, body
where
spojeni.id_hrany = body.id_hrany
order by id_hrany, id_bodu
group by id_hrany
)hrgm
on id_hrany = id_hrany
update hranice_parcel
set geometry = geom.geometry
from
(
select
hp_id,
ST_MakeLine(geometry) geometry
from
(
select
hp_id, sour.geometry
from
spojeni_b_poloh spojeni,
souradnice_obrazu sour
where
sour.id = spojeni.bp_id
order by poradove_cislo_bodu
offset 0
) body
where hp_id is not null
group by hp_id
having count(*)>1 --pridano
offset 0
) geom
where hp_id = hranice_parcel.id;
"Update (cost=730850.00..732569.06 rows=200 width=173)"
" -> Nested Loop (cost=730850.00..732569.06 rows=200 width=173)"
" -> Subquery Scan on geom (cost=730850.00..730855.50 rows=200 width=87)"
" -> Limit (cost=730850.00..730853.50 rows=200 width=55)"
" -> HashAggregate (cost=730850.00..730853.50 rows=200 width=55)"
" Filter: (count(*) > 1)"
" -> Subquery Scan on body (cost=685441.55..713875.14 rows=2263314 width=55)"
" Filter: (body.hp_id IS NOT NULL)"
" -> Limit (cost=685441.55..691128.27 rows=2274687 width=49)"
" -> Sort (cost=685441.55..691128.27 rows=2274687 width=49)"
" Sort Key: spojeni.poradove_cislo_bodu"
" -> Hash Join (cost=56887.43..212019.03 rows=2274687 width=49)"
" Hash Cond: (spojeni.bp_id = sour.id)"
" -> Seq Scan on spojeni_b_poloh spojeni (cost=0.00..72125.87 rows=2274687 width=28)"
" -> Hash (cost=41356.30..41356.30 rows=729530 width=43)"
" -> Seq Scan on souradnice_obrazu sour (cost=0.00..41356.30 rows=729530 width=43)"
" -> Index Scan using ih_hp_id on hranice_parcel (cost=0.00..8.56 rows=1 width=109)"
" Index Cond: (hranice_parcel.id = geom.hp_id)"
ERROR: out of memory DETAIL: Failed on request of size 27. ********** Chyba ********** ERROR: out of memory Stav SQL: 53200 Podrobnosti:Failed on request of size 27.
update tI set cosi = neco_jinyho from tI join ( select id, agregacni_fce(kousicky) neco_jinyho from tI join tII on tI.id = tII.id group by tI.id )dta on tI.id = dta.idcož by ve výsledku nemuselo bejt tak paměťově náročný
Tiskni Sdílej: