Zobrazit příspěvky

Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.


Příspěvky - Pavel Stěhule

Stran: 1 [2] 3 4 ... 31
16
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 11. 07. 2023, 11:57:25 »
Kód: [Vybrat]
    ->  Index Scan using india_foxtrot on golf_sierra  (cost=0.56..525.98 rows=130 width=16) (actual time=0.017..427.026 rows=53864 loops=1)
                            Index Cond: ((six_delta = 'romeo_echo_charlie'::uuid) AND (india_four = 'india_lima'::uuid) AND (kilo >= 'mike_four'::timestamp without time zone) AND (kilo <= 'papa_uniform'::timestamp without time zone))

Tam je problém v brutálně špatném odhadu. Ale těžko říct jak by se dal ten odhad opravit. Za uuid bych na hodinu vyhazoval, a odhad x >= t1 and x <= t2 taky není nejšťastnější. Tady možná přepsat ten dotaz, aby se ten predikát nevyhodnocoval naráz. Možná by stálo přepsat tuu druhou podmínky na výskyt uvnitř časové range.

17
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 11. 07. 2023, 11:29:14 »
Nevies mi poradit ako funguje ta stranka?
Nahral som to tam, vybral som moznost anonymizovat a klikol na Submit. Cakal som, ze tie query plany budu na tej adrese dokial ich nezmazem cez link uvedeny na stranke.

Mne to tak funguje viz https://explain.depesz.com/s/8nwt

18
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 11. 07. 2023, 09:11:24 »

19
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 08. 07. 2023, 12:51:20 »
Vacuum bola prva vec, ktoru som skusil. Nemalo to ziaden vplyv. Skusal som aj updatnut statistiky, ci PostgreSQL si to potom nerozmysli, rovnako bez vysledku. Nastavenia databazy som neriesil. Databaza bezi neviem kde a neviem na com. Riesit to by bolo na 2 tyzdne vysvetlovania a spekulovania ci to je nutne a obav z produkcneho nasadenia akejkolvek takejto zmeny. Je to aj z dovodu vyssie spomenuteho developerskeho vecneho zaciatocnictva a databazy vnimanej ako nutne zlo.
Mam obmedzene moznosti a tak sa snazim s tym urobit co sa da.

Ono jde o to, že pokud máte default shared_buffers 128MB a ta tabulka se do této velikosti nevejde, navíc běžíte na kdoví jakém železe, jak sám píšete, tak index scan může být dost pomalý. Navíc si někdo může přečíst radu typu sniž random_page_cost třeba na nějaký extrém typu 1, a pak optimalizátor může dělat dost divné věci. To jestli je dotaz rychlý ovlivňuje prováděcí plán, aktuální zdraví tabulek a indexů a částečně i konfigurace. Ta konfigurace spíš v extrémech - při rozumném nastavení a rozumném železe nemá velký vliv, ale setkáte se s šílemým nastavením (které u některých dotazů pomůže, ale u jiných hodně uškodí), a setkáte se i s šíleným železem (patologicky poddimenzované železo nebo divně nízký výkon IO nebo CPU (u virtualizace je to docela časté)).

20
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 08. 07. 2023, 11:44:21 »
Oba plany pouzivaju index.
V pripade pomaleho query
Kód: [Vybrat]
Index Scan using dep_document_pkey on dep_document  (cost=0.29..0.36 rows=1 width=16) (actual time=0.234..0.234 rows=0 loops=160742)

Ten index scan u vás není extra rychlý - ještě bych tabulku zvakuoval (což by se mělo dělat jako první krok při řešení performance problému), a pak zkontroloval nastavení shared_buffers a random_page_cost. Tak se může chovat podstřelené nastavení random_page_cost. Na mém notebooku mám o 2 řády rychlejší čas.

21
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 08. 07. 2023, 09:37:37 »
Muzete ukazat cele provadeci plany? https://explain.depesz.com/ umi anonymizaci. Evidentne tam mate nested loop nad primarnim klicem. Zkontrolujte si jestli nemate ten index bloatly, pripadne muzete penalizovat nested loop - `set enable_nestloop to off`. Z toho zlomku, co jste ukazal by mozna mohl pomoct podmineny index. Postgres pri odhadech nejde na 0, nicmene ve vasem pripade tam ty hodnoty, ktere se hledaji, evidentne nemate.

V zasade jde o to pochopit, jak funguje optimalizace dotazu - v pripade modernich SQL databazi optimalizace zalozena na statistikach, a v cem a jak muze tato optimalizace chybovat. A pak se snazite a) eliminovat chyby, nebo b) vytvarite prostor nebo zuzujete prostor pro optimalizaci. Jednodussi dotaz vytvari mensi prostor pro optimalizaci, komplexnejsi vetsi prostor pro optimalizaci. Na internetu nic moc uceleneho nenajdete, alespon ja o tom nevim. Jsou dobre prezentace, ale vetsinou zamerene na jeden konkretni problem (protoze se vetsinou musite vejit do limitu 50 nebo 90 minut). Videl jsem par knizek, a mam i "PostgreSQL Query Optimization, Dombrovskaya, Novikov, Bailliekova", ktera je slusna a je urcena pro zacatecniky (jak znam typicke znalosti vyvojaru pouzivajicich databaze, tak vyjma par expertu, jsou prakticky vsichni vecni zacatecnici). Pak je to o zkusenostech. Ja se tim zivim. Budto skolim, anebo resim performance problemy. Za 20 let uz si pak clovek udela docela prehled (a jeste se motam kolem vyvoje Postgresu, i kdyz hodne daleko k optimalizaci). Tady v CR (i svetove) je spicka Tomas Vondra, ktery napsal do Postgresu podporu vicesloupcovych statistik, ted se mota kolem BRIN indexu a replikace. Muzete zkusit hledat nejake jeho prezentace na netu.

22
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 05. 07. 2023, 05:34:31 »
Zkuste snížit hodnotu random_page_cost

Pokud oba plány používají index, tak to nepomůže.

Já jsem z toho jak je to popsané pochopil že index se v jednom plánu nepoužívá a tento plán se volí se dokud je v tabulce málo záznamů. To je přesně případ ve kterém mi pomohlo snížit hodnotu random_page_cost - samozřejmě netvrdím že to pomůže i v tomto případě, ale připadá mi že by stálo za to to zkusit.

Ja to pochopil jinak - viz věta "Pri pomalom sa nepouzije a PostgeSQL skenuje celu tabulku za pomoci primarneho kluca(ID je v primarnom kluci)". Nicmeně jelikož tazatel nemůže zveřejnit prováděcí plány, tak stejně všichni tu střílíme naslepo, což je jen ztráta času. Kdo ví, co tam je za problém - také to může být nezvakuovaná nebo bloatnutá tabulka, nebo chybějící více sloupcová statistika.


23
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 04. 07. 2023, 22:06:54 »
První co mi nedá: je to opravdu pokaždé textově stejné SQL (a ty vyhledávací parametry se předávají nabindovanou proměnnou), nebo se do něj parametry stringově naconcatujou?
Tj "select ... where datum between ? and ?" vs "select ... where datum between to_date('2023-01-01') and to_date('2023-02-01')"
(jestli to není stejný string, tak se klidně může nacacheovat úplně jiný plán ...)

Bacha, Postgres není Oracle. Nemá implicitní plan cache.

24
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 04. 07. 2023, 08:31:09 »
Zkuste snížit hodnotu random_page_cost

Pokud oba plány používají index, tak to nepomůže. Navíc pokud nemáte SSD, tak je snížení random_page_cost dost problematické, něco zrychlí, něco může zase fatálně zpomalit. Základem je pochopit proč se použije špatný plán, slepě mačkat všechna tlačítka většinou nepomůže.

25
Server / Re:PostgreSQL - vynutenie pouzitia jedneho query planu
« kdy: 03. 07. 2023, 20:10:37 »
Těch důvodů proč se použije špatný plán může být vícero. Od špatných odhadů až po nehomogenní uložení dat. Bez znalosti dotazu a prováděcího plánu se nedá říct vůbec nic. Postgres žádné fixování plánů nemá. Pokud nemůžete zveřejnit informace, obraťte se na svůj placený support.

26
Kdykoliv se upraví třídící algoritmy v glibc, tak je nutná reindexace všech indexů textových typů. Detaily teď v hlavě nemám, verzování collation na glibc vychází z verze glibc, ale to může způsobovat falešné alarmy. Doporučuje se přejít na ICU, kde je k dispozici sémantické verzování pro každé collation, tudíž to zbytečně negeneruje falešné alarmy. Hlavně je důležité reindexovat databázi, kde máte data. Databáze Postgres je pískoviště, a template1 se používá pouze při zakládání nových databází.

27
Vývoj / Re:Kontrola propojení tabulek v SQL databázi
« kdy: 28. 04. 2023, 20:09:31 »
Pro pana Jirsáka, děkuji, je to ta druhá možnost, zajímalo mě právě, zda na to není nějaký šikovný trik z praxe a tak.., kromě té analýzy.

Na to žádný nástroj nemůže existovat. Data v relační databázi budou přesně v modelu, který jste si nastavil. Tudíž nějaká univerzální kontrola vůči tomuto datovému modelu nemůže najít nějakou odchylku. Abyste zjistil chybu, tak byste musel porovnat data s reálným světem nebo s jiným datovým modelem. Pak zjistíte rozdíly, ale je zase pak otázkou interpretace jestli jde o chyby nebo záměr.

28
Vývoj / Re:Kontrola propojení tabulek v SQL databázi
« kdy: 28. 04. 2023, 16:34:21 »
Ve vaší otázce mícháte dvě věci. Jednak kontrolu implementace referenční integrity, druhak kontrolu vámi navrženého datového modelu. Pokud definujete referenční integritu, a ona by nefungovala, tak by se vám objevovali sirotci - hodnoty jejichž cizí klíč by nebyl validní - lze to testovat např. outer joinem.

Kvalitu datového modelu popisují tzv normální formy. V reálu se nekvalitní model projeví buďto duplicitou dat, nebo s údržbou dat - např. nebudete moc přidat další kontakt na zákazníka nebo uživatele, nebo se vám budou špatně psát SQL dotazy. Viděl jsem vývojáře vesele pracovat s extrémně nešikovně navrženou databází - od problémů je odstínilo ORMko. Bylo to ale za cenu problémových SQL dotazů a častého zamykání (což se pak negativně projeví na výkonu).


29
Vývoj / Re:Jak funguje cache v relační databázi?
« kdy: 02. 03. 2023, 07:24:06 »
Zdravím,

řekněme, že mám databazí a v ní tabulku s nutričními hodnotami potravin: FoodsTable.

Uživatelé na frontendu často potravinami listují, když vyhledávají fulltextem. A řekněme že tento query spouštím jako parametrized query:

Kód: [Vybrat]
var pstmt = con.prepareStatement("SELECT * FROM FoodTable WHERE name like CONCAT( '%',?,'%')");
pstmt.setString(1, notes);
var rs = pstmt.executeQuery();

Databáze bude řekněme Postgres a celkový objem dat v tabulce FoodTable bude řekněme 50MB.

Tzn. otázka zní, má v takovém případě vůbec smysl uvažovat o nějaké In memory cache přímo v Javovské aplikaci, když už relační databáze na své straně umí cachovat? A jak to vlastně ta databáze cachuje, drží si výsledky toho query in-memory, nebo to funguje jinak?

PS: Např. SQLite cachovat umí, ale těžko to je In-Memory cachování, spíše si tu cache nějak zapisuje na disk do souboru.

V databázi je několik různých cache - třeba v Postgresu - máte sdílenou cache datových stránek, lokální type cache, lokální cache plánů předpřipravených dotazů. Postgres necacheuje výsledky dotazu - ale v share buffers má data, které potřeboval pro zpracování dotazu a opakovaně (pokud zůstanou v cache) už je nečte z file systému (kde je další cache).

Přístup do lokální cache je výrazně rychlejší než přístup do Postgresu nebo jakékoliv jiné SQL databáze(minimálně o řád, ale možná ještě o víc). Jakmile přistupujete k databázi, tak máte režii síťové vrstvy, parseru, executoru (i když používáte prepared statements). Navíc v relačních databázích je dost velká režie zajištění konzistence dat - proto se používají i inmemory databáze jako je redis, kde je sice síťová režie, ale nulová režie s konzistencí a malá režie s protokolem.

Pokud neřeším konzistenci dat, tak je lokální cache vždy výhra (pokud se mi data vejdou do RAM, a pokud budu mít zahřátou cache). Jakmile se začne řešit konzistence dat - tak použití lokální cache (zvlášť jsou data v cache delší dobu) tak je spíš problém - musíte řešit jak synchronizovat data, jak zamykat data (když máte víc aplikačních serverů), jak optimálně zahřát cache, kdy invalidovat cache, ...

V praxi se používá mix - některá data se dobře kešují lokálně, jiným je dobře v redisu -  a zbytek se nechává v databázi a lokální cache se použije maximálně v rámci transakce. Hodně záleží na očekávané zátěži - i bez lokální cache a se správnými indexy může databáze vracet dotazy v řádech ms, což pro většinu aplikací bohatě stačí.

Jinak on ten přístup do RAMky také není nekonečně rychlý - pro trochu větší data se musí použít hash tabulky nebo stromy, a s tím je spojená nějaká režie (ať už CPU nebo RAM).

30
Vývoj / Re:Lua a cyklus
« kdy: 24. 02. 2023, 06:57:19 »
BTW když už tu je tolik odborníků na LUA, nemohl by někdo doporučit z toho milionu co jsou na netu k dispozici nějaký rozumný quick tutorial? To znamená žádné rozvláčné rozepisování (už vůbec ne video), ale základní principy jazyka, datové typy (třeba jako to jak tu padlo že pole jsou od jedné) a pár triviálních příkladů atd.
...zhruba ve formátu, jak tu pan Tišnovský občas popisuje různé exotické jazyky :)

viz https://www.root.cz/clanky/programovaci-jazyk-lua/

Stran: 1 [2] 3 4 ... 31