Názory k článku Zákys jménem flattening
-
mys elf (neregistrovaný)Milý kolego, kdybyste v dětství více četl, měl byste lepší známky z diktátu, znal byste rozdíl mezi tvarem některých slov ve třetím a čtvrtém pádu a možná byste i věděl, že korektně napsaný text bez gramatických chybek se dá lépe a rychleji číst.
Moje námitka byla k formě a nikoliv k obsahu článku. Pokud Vám nevadí, že Vám (když to přeženu) v prvotřídní restauraci přinesou velmi chutné jídlo ledabyle naházené na otřískaný talíř, je to Vaše věc, ale já si myslím, že mám právo se vyjádřit i k formě článku.
Pokud Vás vytáčí i tak slušně napsaný příspěvek, jako byl ten můj, doporučuji konzultovat problém s psychologem. -
Smyslem clanku je upozornit na urcite chovani PostgreSQL. Tise predpokladam, ze ti, co pochopi o cem je rec, znaji prikaz create index a dokazi jej pouzit. Neni to clanek, ktery je urcen zacatecnikum. O samotne indexy take nejde. Jadro pudla je ve statistikach, ktere nedostatecne presne popisuji data (rozdil mezi skutecnym poctem radku a predpokladanym poctem radku). Z toho se pak odviji zbytek. -
PaJaSoft (neregistrovaný)Kolego, gratuluji ke ctivemu (na to, ze je to sucha otrocina a skoro alchymie jste se toho ujal velice bravurne - BRAVO!) clanku, co Vam vsak nemohu jednoduse odpustit je vase, dle meho nazoru nemistna, poznamka na tema realneho pouziti PostgreSQL 7.4 a vyse. Na cempak asi bezi ty tisice projektu, ktere jako backoffice maji PostgreSQL v ruznych podobach vice jak dvacitku let? Chcete rici, ze PostgreSQL konecne dospel po tom bezmala petadvacetiletem vyvoji? Porovnaval jste Oracle (zrejme mate zkusenosti) - docela by mne zajimalo, kdy (v jake verzi) dospel z vaseho pohledu on...:)
-
Vývoj Oracle nesleduji, takže nemohu sloužit. Tou poznámkou jsem nemyslel nic jiného, než že ve verzi 7.4 byly odstraněny ty nejhorší bugy, což je jeden z důvodů rozšíření 7.4. To, že ještě dneska se používá jako backend (případně ještě starší verze) považuji za katastrofu. Samozřejmě to, že se v Iraku obden pozabíjí stovka lidí je katastrofa taky. Trochu to vypovídá o lenosti a pohodlí vývojářů - alibismu, nebo o dohnívajících aplikacích, které už nikdo neudržuje. Není to jenom otázka PostgreSQL - MySQL 3.x, MsSQL 6.5, ... 99% aplikací nemá regresní testy, unit testy, takže vím, že není problém přeportovat, ale otestovat aplikaci.
V o.s. Vám nic nebrání udržovat soft aktuální. Navíc náklady a rizika s portem jsou podstatně nižší, pokud aktualizujete často, než když aktualizace neprovádíte. Je jasné, že přenést aplikaci z 7.2 může být celkem riziko do 8.2, zatímco z 8.1 do 8.2 je to na 99% dump/reload. Dost často se setkávám s 7.4 a daří se mi uživatele přesvědčit, aby přešli na 8.1. Nelitují. O 7.3 jsem nedávno slyšel. Možná se používají ještě starší verze. Pro soft, který je mrtvý, je to jedno. Pro udržovaný sw lituji všechny co s tím musí dělat.
Jinak je debata k pivu. Proč firmy ještě používají kolikrát VB, když teď je k dispozici řádově lepší .NET? SW průmysl je drobátko konzervativní, drobet pokrytecký. Proč se pouštět do aktualizací dobrovolně a na své triko, když je za pár let zaplatí zákazník, a programátoři to ještě pár let vydrží. Proč si neudělat jméno dodáním vylepšené verze, která běží řádově rychleji, kdy za 90% zrychlení je zodpovědná nová verze a 10% oprava bugů. Proto používám o.s. :-) -
ugra karma (neregistrovaný)da se to taky resit pomoci subtables nebo funkcionalnich indexu.
preferuji subtables, jelikoz se s nima da v pripade potreby primo manipulovat. takze problematicka data nacpat do nich a problematicke selecty prekodovat.
jinak by bylo dobre, aby nekdo nakodil utilitu, ktera na danym stroji udela testy a vyplivne nastaveni cost pro optimalizer na zaklade rychlosti cpu a disku. -
ugra karma (neregistrovaný)ja osobne bych ocenil pomalejsi vydavani novych verzi, idealni by bylo tak jednou za dva, lepe tri roky ala oracle.
podle http://www.postgresql.org/developer/roadmap to vypada na novou verzi po 6 mesicich. Rychle vydavani novych verzich zbytecne zvysuje cenu za udrzbu. Proto doufam ze zacnou pracovat na nejakem big feature, ktere je dostatecne dlouhou dobu zamestna. -
U Open Source je vyhodnejsi kratsi cyklus. Hromada patchu je od nezavislych vyvojaru, firem a nikomu se nechce moc dlouho cekat, a pak si praci s patchema rozmysli. Na kratsi cyklus prechazi i Firebird. Nikdo Vas nenuti prechazet na novou verzi pokazde, kdyz se vyda. Podporovane by mely byt posledni dve verze.
S 8.3 je to trochu vyjimka. Ukazuje se, ze zmrazeni kodu po dovolenych neni uplne idealni, a ze programatori jsou taky lidi, a chteji jet na dovolenou s cistou hlavou. Takze aby se nastartoval cyklus na polovici roku, se 8.3. vydava ve zkracenem terminu. Jinak by se mel drzet rocni cyklus. -
krtek (neregistrovaný)Velmi pekny clanek, sice ja delam s Oracle, ale rad si prectu i o jinych databazich aby byl clovek trochu v obraze.
Nevite proc se tak brani zavedeni hintu, v oracle je to bezna vec ktera celkem dost pomaha. Normalne clovek vsechno nechava na optimalizatoru a az v pripade nejakych problematickych dotazu clovek vetsinou optimalizuje rucne a to vetsinou pomoci hintu. -
Je to o filozofii. Pokud pouziji hinty aniz bych vedel o duvodech chovani databaze, tak je vetsinou pouziji spatne. Pokud znam databazi, tak zase vetsinou nepotrebuji hinty :-). PostgreSQL indexy pouziva naprosto bez problemu. Nesmi se jen zapominat na ANALYZE. Dost casto hint vede k tomu, ze optimalizujete dotaz pro jednu specifickou podmnozinu dat, a pro dalsi dotaz s hintem bude provaden neefektivne. Takze se hinty chapou jako neco, co umoznuje zacatecnikum napsat neco co je rychle a spatne, a tudiz je to zavrzenihodne. Je lepsi, kdyz si zacatecnik uvedomi, co ma za problem, pripadne se zepta a vyresi problem korektne (tj. bez pouziti hintu ;-)). A zase, vuci ostatnim o.s. databazim, PostgreSQL ma planer o dost sofistikovanejsi (coz neni vzdy vyhoda, pro jednodussi dotazy je pomalejsi nez u MySQL).
-
ugra karma (neregistrovaný)jo chce to podporu pro uzivatelem nastavovatelne jak moc ma planer optimalizovat http://www.pdc.kth.se/doc/SP/manuals/db2-7.1/html/db2s0/frame3.htm#sqls0661
jinak db2 je zadara pro linux i pro komercni pouziti. vubec db2 je hezka db, kdyz porovnate sql jazyk oracle a mysql, tak db2 ho ma nejlepsi, nejsou tam zadny nadstandardni zbytecnosti pro ruzne speedup hacky.
btw proc name pgsql podporu pro release savepoint? mysql to uz umi. -
Petr (neregistrovaný)Chapu, co pisete, ale prijde mi to jako purismus; jako povyseni idelogie nad praktickou pouzitelnost.
A v praktickem software, aspon ve vsech projektech, kdy jsem se pohyboval, je dulezitejsi predikovatelnost doby nejhorsiho pripadu nezli prumerny cas nebo cas nejlepsiho pripadu. A podle me zkusenosti mi tuto predikovatelnost da hint, nebot hintem stabilizuji execution plan; jinak nikdy nevyloucim, ze mi spatna statistika vytvori nekolikadenni selecty.
Chapu, ze SQL je vymyslen jako jazyk typu "reknete mi, co vam mam dat, ne jak to mam ziskat" a ze hinty zkali tuto jeho pruzracnost.
Ovsem z druhe strany vzato: Optimalizator se ze statistik snazi zjistit vztahy mezi daty, podstatne pro efektivni provadeni prikazu. V aplikacni domene se ale muze stat, ze mezi daty jsou dalsi vztahy, ktere ze statistiky nezjistim (jako ze statistiky datumu nezjistim, ze po pondelku vzdy nasleduje utery). Pak potrebuji zpusob, jak bud optimalizator vyradit a zoptimalizovat to sam, anebo jak optimalizatoru ten vztah vysvetlit. "Hint" a "doprogramovavani optimalizatoru" jsou pak uz jen ruzne odstiny tehoz principu, pricemz hint je jednodussi, prehlednejsi a mene riskantni. -
anonymníHinty jsou proste diskutabilni tema. Osobne vsem radim, aby aplikaci pravidelne monitorovali a prubezne ladili. Jak to uz zalezi na konretnim databazovem systemu. Hintama, prepsanim dotazu, .. Pravidelne se objevuji navrhy na zavedeni hintu do pg. Zatim jeste nikdo nemel dostatek energie a nezduvodnil je dostatecne aby presvedcil Toma Lane. Primarne se v pg jde cestou co nejsofistikovanejsiho optimalizeru. Zase, jedna se o o.s. Pokud napisete patch, obhajite jej, tak se v core objevi. Ale muzete mi verit, ze to jsou obcas dost velke bitvy.
-
Martin Kavalec (neregistrovaný)Taky mi to připadá jako fundamentalismus říct, že hinty jsou špatné a basta. A v tomto světle je pak čiré farizejství, když si tam jeden hint převlečený za OFFSET nechají; když už optimalizovat, tak pořádně a OFFSET 0 by se měl vyhodnotit jako zbytečná klauzule, ne? Když to dotáhnu ad absurdum, tímto stylem by se taky mohlo zakazovat použití indexu přidáním "AND sloupec=sloupec" do klauzule WHERE.
Ne vždycky je nutné nad tabulkou vytvářet statistiky -- např. při různých agregacích a transformacích dat pro datový sklad. Např. vím, že ve vstupní tabulce mám ke každému identifikátoru max. 3 záznamy a unikátních identifikátorů jsou tam třeba 3 miliony a tuto tabulku potřebuju sumarizovat podle těch ID. Planner to chce groupovat hashováním, protože netuší, ze těch unikátních identifikatrů je tolik. Buď mu můžu říct, ať si spočítá statistiky, anebo připsat na konec dotazu kouzelné "option (order group)", čímž mu poradím, že je rychlejší si tabulku sesortovat a pak už jet sekvenčně. (což se testováním ukázalo jako rychlejší a po vytvoření statistik na to planner přijde taky) Ale vzhledem k tomu, že tato operace je jednorázová, pak se tabulka smaže a příště se bude agregovat zase nová tabulka, je to vytváření statistik trochu drahý "hint". (ten zápis hintu je pro MS SQL, čímž taky odpovídám na dotaz někde v diskuzi, jestli MS SQL má hinty)
Každopádně, uznávám, že je to dost specifický případ. Asi bych si hodně rozmýšlel použít hint někde v kódu aplikace, kde fakt hrozí, že sice zrovna teď mi to pomůže, ale až se změní charakter dat, tak si na tom ta aplikace vyláme zuby, kdežto se statistikama se tomu prostě přizpůsobí.
Jinak pro zajimavost, někdy před rokem a půl jsem u Postgresu narazil na toto zajímavé chování:
explain select neco_id from tabulka where neco_id between 100000 and 150000 order by neco_id;
navrhoval použít seq scan tabulky (a bylo to pomalé, v tabulce bylo tusim cca 700 tis. záznamů).
Pokud jsem to přepsal na
select * from
(select neco_id from tabulka where neco_id betweeen 100000 and 125000
union all
select neco_id from tabulka where neco_id betweeen 125001 and 150000) x
order by neco_id
tak uz se pouzil index scan (+ append).
Na tom, ze hinty jsou spatne asi neco bude, protoze me to aspon prinutilo podivat se do manualu a upravit parametr random_page_cost a pak se pouzil index i v prvnim pripade. Ten analyzer vykonostnich charakteristik disku, jak nekdo v diskuzi navrhoval, asi neni spatny napad :) -
> tak uz se pouzil index scan (+ append).
> Na tom, ze hinty jsou spatne asi neco bude, protoze me to aspon prinutilo podivat se do
> manualu a upravit parametr random_page_cost a pak se pouzil index i v prvnim pripade.
> Ten analyzer vykonostnich charakteristik disku, jak nekdo v diskuzi navrhoval, asi neni
> spatny napad :)
Kdyby zalezelo jenom na rychlosti disku. Zalezi na taky na velikosti pameti a na velikosti diskove cache vcetne systemove. Random_page_cost bych se bal zmenit, zato efective_cache_size je na linuxu poddimenzovana a doporucuje se zvysit. Obecne 8.1 ma poddimenzovanou konfiguraci a chce to pouzivat hodnoty, ktere jsou v 8.2. Dost to pomuze. -
Marek Jakub (neregistrovaný)V zásadě platí, že hint by měl dodat optimalizátoru dodatečnou informaci, kterou ze statistik nedostane, nebo je zavádějící.
Nepoužívám a neznám PostgreSQL, používám ORACLE, ale i tato finta může být nebezpečná a dost bolet. Jde o to, že použitím OFFSET 0 podle mého názoru dojde k materializaci poddotazu (vytvoření výsledku v temporary paměti) a pokud je výsledkem poddotazu velká množina, tak výsledek může být horší než použití suboptimálního indexu.
To byl zřejmě případ Vašeho kolegy, který 10% dotazů zrychlil a u zbylých 90% došlo k trojnásobnému spomalení. Prostě to nejde použít pokaždé, pokud by to šlo, optimizer by to už dávno tak dělal :-)
Jinak v ORACLE se používá stejný trik právě tehdy, kdy chcete provést materializaci poddotazu, protože není vhodné, aby optimizer použil unnesting (nevím český ekvivalent a odhnízdění mi přijde divné). Použije se rownum, což je virtuální sloupec, který počítá řádky výstupu. Pokud bych použil Váš příklad, tak ten dotaz by vypadal takto:
select * from (select t1.*, rownum r from t1 where a = 20) s where s.b = 20
Toto provede v podstatě totéž, čehož chcete dosáhnout Vy, tj. vyhodnotí nejdříve vnořený dotaz, a na to aplikuje filter b = 20.
Protože tímto trikem napravujete statistiky, které neodpovídají datům, další technikou, která je použitelná v ORACLE, je modifikace statistik, ale to už je většinou černá magie a měla by být používaná ještě s větším rozmyslem, než "flattening" -
Marek Jakub (neregistrovaný)Doufám, že to nevyznělo, že modifikace statistik je v ORACLE běžná praxe. Osobně jsem ji ještě nikdy nepoužil. Domnívám se, že k takovému voodoo se dospěje až při databázích v řádu stovek Gb - Tb.
Nevím jak probíhá sběr statistik v pg, ale v ORACLE se u tak velkých tabulek obvykle skenuje pouze vzorek cca 1-5%, což stačí, pokud jsou data rovnoměrně rozložena. Pokud ale nejsou, nebo se náhodou při sběru trefíte do blbých částí, tak statistiky neodpovídají skutečnosti. Pak nastává čas pro voodoo se statistikama.
Nebo když máte aplikace, které nevěří na NULL hodnoty (různé systémy, které jsou "multidatabázové") a tudíž místo NULL používají nějakou konstantu, např. 1.1.1900 pro datum, tak mají problém, protože matou optimizer. Ten spočívá v tom, že optimizer předpokládá, že hodnoty jsou v prostoru rovnoměrně rozdělené a přitom mezi 1.1.1900 a např. 1.1.2000 nemáte žádnou hodnotu, ale mezi 1.1.2000 do 1.1.2007 máte dejme tomu 1mio záznamů. Běžně ale děláte dotazy na konkrétní den, přičemž optimizer si myslí, že na jeden den připadá cca 25 záznamů (1m/39081), ale ve skutečnosti jich je 391 (1m/2557). Při malých datech ten rozdíl není podstatný, ale čím více dat, tím více bude v takových případech optimizer dělat chyby.
Obdobný problém může nastat, pokud se použije např. 1.1.4000 pro nekonečno.
Záludnost modifikace statistik je v tom, že má vliv na všechny dotazy nad danou tabulkou. A nejhorší je, že když statistiku opravíte tak, že odpovída skutečnosti (např. odstraníte vliv toho 1.1.1900), tak vám přestanou fungovat již odladěné dotazy.
V tom mají hinty velkou výhodu, protože i když neřeší přičinu (chybné statistiky), ale mají pouze lokální vliv, takže opravujete pouze to co nefunguje. -
Použil, dokud jsem jak trotl poslouchal starší borce, naštěstí v aplikaci, která nikdy nebyla v provozu. Ale i tak se za to stydím, a beru to jako hřích mládí :-). Pokud si nevystačím s hodnotou NULL (což se může stát), tak si přidám jeden flagovej sloupec navíc. 100x se to vyplatí. Prostě už jsem vyrostl, z toho, bych se snažil ušetřit bit. Dobře mne vyškolil Postgres. První patche, který jsem tam posílal, přepsali, tak že jsem je nepoznal. A když už si mysleli, že bych mohl dostat rozum, tak mi patch 10x omlátili o hlavu. O magických číslech kolujou úžasný historky, kvůli tomuhle nešvaru padaly rakety, letadla. Naštěstí v bezpečných aplikacích, které procházejí několikanásobným auditem už to nikoho nenapadne. Jinak bych se bál sednout do letadla.
Viděl jsem hromadu ****** systémů, které v podstatě nelze udržovat, ook, na jednom jsem se před pár lety i podílel. Snažím se trochu myslet, by výsledek nějak vypadal. S trochou úsilí se dá dobře psát i ve VB nebo PHPku, s MySQL. Chce to mít ale na zdi velký nápis: Mysli! a nedělej blbosti. Hledat na netu, číst a snažit se nad vším přemýšlet. A nemyslet si, že jsem spolkl veškerou moudrost světa. Každá verze sw je trochu jiná, s každou se dá psát o fous slušněji, čistěji, spolehlivěji. -
Marek Jakub (neregistrovaný)Většinou nejde o to ušetŕit bit, i když to implemetačně je několik bajtů, o to dnes skutečně nejde. Pokud si někdo jěště hraje s místem, tak je to buď nadšenec a trochu blázen, nebo to diktují hw podmínky, pouźití v settop boxech a podobně.
Podstatná je ale udržovatelnost sw, kde můžete narazit na to, že akademicky čisté řešení je výkonnostné nepoužitelné. Chce to rozpoznat tu hranici, kde trvat na čistotě, a kde je vhodné ustoupit. Někdy to je těžké a s odstupem času se můžete hrozit, co jste to napáchal, když šlo použít mnohem elegantnější řešení.
Pokud se vrátím k vyjádření nekonečna konstantou, a úkol zjišťování kolize dnou časových intervalů <a,b> a <c,d>. Tak při použití konstanty pro -nekonečno a +nekonečno je vyhodnocování průniku triviální podmínkou (a <= d) and (c <= b), která se za jistých podmínek dá i indexovat a dá se s tím rozumně žít. Puristické použití Vaší metody vede k brutální podmínce, která indexovat možná nejde vůbec.
Podle mne je řešením kompromis, kde uživatel sice zadává počátky a konce intervalů a flagem označuje, jestli se jedná o +-nekonečno (A, IS_INFTY, B, IS_INFTY), nicméně aplikační vrstva naplní ještě extra atributy, třeba X_A a X_B (které uživatel nevidí a nemá možnost změnit), kde -+ nekonečno nahradí přísl. konstantou, která je zadrátovaná pouze na tomto jednom místě. A úkol je vyřešen vcelku elegantně a čistě.
Ale tím jen opakuji to co říkáte, že téměř vždy lze nalézt čisté řešení. -
ugra karma (neregistrovaný)chce to lepsi vacuum analyze. v soucasne dobe dela tohle:
INFO: vacuuming "data"
INFO: "data": found 0 removable, 1063474 nonremovable row versions in 9001 pages
DETAIL: 0 dead row versions cannot be removed yet.
There were 1034 unused item pointers.
30 pages contain useful free space.
0 pages are entirely empty.
CPU 1.39s/0.97u sec elapsed 6.10 sec.
INFO: analyzing "data"
INFO: "data": scanned 3000 of 9001 pages, containing 354595 live rows and 0 dead rows; 3000 rows in sample, 1063903 estimated total rows
VACUUM
udela sice celej tablescan kvuli vacuum, ale pro analyze stejne pouziva jen 3k stranek (da se to nekde zvetsit?). Chtelo by to aby uz kdyz projizdi celou tabulku a generuje io, aby ziskana data laskave pouzil i pro analyze. to snad neni tak tezky nakodit. -
jak je to presne nevim, ale urcite to zavisi od nastaveni statistik.
postgres=# ALTER TABLE lo ALTER COLUMN x SET statistics 10; ALTER TABLE postgres=# analyze verbose lo; INFO: analyzing "public.lo" INFO: "lo": scanned 3000 of 4406 pages, containing 681000 live rows and 0 dead rows; 3000 rows in sample, 1000162 estimated total rows ANALYZE postgres=# ALTER TABLE lo ALTER COLUMN x SET statistics 100; ALTER TABLE postgres=# analyze verbose lo; INFO: analyzing "public.lo" INFO: "lo": scanned 4406 of 4406 pages, containing 1000000 live rows and 0 dead rows; 30000 rows in sample, 1000000 estimated total rows ANALYZE
-
Predpokladam, ze databaze postavene na sitovem nebo hiearchickem modelu by timto neduhem netrpeli. Proste tam planer neexistuje, a tudiz nemuze mit ani problemy. Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim. K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. Do tretice, jedna se o vyjmecne pripady. Cim castejsi by byly, tim lepe se bude planner chovat. A uplne posledni argument. Pokud bych to bral jako nevyhodu, pak je to problem jedne implementace relacniho modelu, nikoliv problem samotnych relacnich databazi.
Je to rozdil mezi proceduralnim a neproceduralnim programovanim. Pri proceduralnim pristupu zalezi vic na kvalite programatora. Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. -
honza (neregistrovaný)[...]Predpokladam, ze databaze postavene na sitovem nebo hiearchickem modelu by timto neduhem netrpeli. Proste tam planer neexistuje, a tudiz nemuze mit ani problemy.[...]
100%
[...]Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim.[...]
hmm, ale my technici takove vety prenechavame politikum, protoze jsou pod nasi uroven, ne ...
[...] K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. [...]
??
[..]Do tretice, jedna se o vyjmecne pripady. Cim castejsi by byly, tim lepe se bude planner chovat. A uplne posledni argument. Pokud bych to bral jako nevyhodu, pak je to problem jedne implementace relacniho modelu, nikoliv problem samotnych relacnich databazi.[...]
to ano, ale viz nize
[...]Je to rozdil mezi proceduralnim a neproceduralnim programovanim.[...]
neznam aplikaci (napr. nejaky informacni system), ktera by se obesla bez proceduralni slozky(src:vlastni zkusenosti :-))
[...]Pri proceduralnim pristupu zalezi vic na kvalite programatora.[...]
Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.
[...]Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. [...]
?? - databaze programuje prece i nadale par silencu a ostatni si o nich mysli ze jsou borci. Minite databazove aplikace?
Moje poznamka se netykala ani tak toho konkretniho problemu s analyzatorem, spise jsme chtel poukazat na to, jaky obrovsky aparat se kolem tohoto modelu vybudoval. Vas clanek je jednim z mnoha milionu, ktery se zabyva s nejakou castecnou problematikou.(src:internet,diskuze k databazim) A diskuze zde to take nadherne potvrzuje. Jeden je pro hinty, druhy je v postgresql nechce videt, treti uz s nimi pracoval, ale jen pod Oracle a nyni uz chybi, aby rekl ze to bylo ve verzi 9.1.x.7, rel.12 a ze v te verzi 10.0.1.3 rell.xxx je to zase trochu vylepsene s tim, ze zase zmenili ty subselecty ... apod.
To podstatne je, (bohuzel), ze den ma jen 24 hodin(src:ustav pro miry a vahy). A budto v tomto case bojuji s problemy, ktere mi pred nohy hodil nejaky model, nebo se venuji problemum zakazniku.(src:polemika :-)) -
Marek Jakub (neregistrovaný)Osobně jsem programoval mission critical "databázovou" aplikace ještě v MSDOSu v knihovně Btrieve, nebo jak se to jmenovalo, což byla souborová databáze. Veškeré řízení bylo procedurální včetné použití indexů. Nedokážete si představit, jaký to byl opruz a jak to bylo těžké. To co dnes řeším napsáním jednoho ad hoc dotazu během minuty, byla práce na několik hodin.
I první verze FOXky a jí podobných to řešila podobně, ale byly k dispozici dokonalejší nástroje pro práci s daty, nicméně podstatná ćást práce byla stejně procedurální. Joiny znala FOXka myslím až v nějaký pozdějśí verzi.
Relační databáze, resp. jejich implementace přinesli zjednodušení v řádu několika řádů. Standardizace SQL umožnila vznik mnoha nástrojů pro práci s daty. Dnes to považujeme za standard a proto pláčeme nad klacky, které nám implementace hážou pod nohy, ale věřte, že borci kteří tehdy DB aplikace psali byly tehdy asi takového kalibru, jako dnešní vývojáři nízkoúrovňoví céčkoví unixáři.
Jsem přesvědčen, že budoucnost bude z velké části neprocedurální, protože požadavky na rychlost vývoje a kvalitu kódu budou růst a kvalitních vývojářů bylo, je a bude málo. Dokonce mám pocit, že jich je pořád méně.
Vidím ty umělé inteligence, kterým řeknete, že chcete něco jíst a ony Vám podle Vašeho zdravotního stavu, nálady a nevím čeho nabídnou a uvaří nějakou dobrotu. :-).
Jestli nakonec vyhraje relační model, nebo hierarchický, či síťový je v zásadě jedno, protože budoucí vývojáři už ani nebudou vědět co to je. -
>>[...]Na druhou stranu relacni databaze jsou podstatne adaptabilnejsi a jednodussi oproti svym predchudkynim.[...]
> hmm, ale my technici takove vety prenechavame politikum, protoze jsou pod nasi uroven, ne ...
Když mám dobře zabezpečenou databázi, tak mohu pustit proškoleného uživatele s crystal reports (či jiným sw) do databáze, by si vytvářel reporty sám. Zpravidla nemusí mít ani znalost SQL (nicméně to není naškodu). Díky relačnímu modelu mohu celkem jednoduše vytvářet nové vazby (třeba virtuální). V jiných modelech už musím programovat. Někdo preferuje programování, někdo parametrizaci. Já, to je jasné, parametrizaci.
>> [...] K tomu jeste, pokud vim, ze data maji tento charakter, tak mohu svoji aplikaci vuci tomuto chovani obrnit. Skutecne jednoduse. [...]
> ??
Stačí mi jedna tabulka s počty výskytů. Tu stačí aktualizovat jednou za čas. Předřadím SELECT do této tabulky, a pak provedu čistý dotaz nebo dotaz s OFFSETEM.
[...]Je to rozdil mezi proceduralnim a neproceduralnim programovanim.[...]
neznam aplikaci (napr. nejaky informacni system), ktera by se obesla bez proceduralni slozky(src:vlastni zkusenosti :-))
já také ne. Nicméně pokud něco lze vyřešit neprocedurálně, preferuji neprocedurální přístup. Pro většinu neprogramátorů je výsledek čitelnější. Nemyslím si, že SQL je absolutně přenositelný, nicméně SQL dotaz zapsaný pro Oracle by měl dokázat přečíst i ten, kdo se učil SQL na Microsoftu. Neznám podobný standard, který by existoval pro nerelační databáze.
Netvrdím a tvrdit nikdy nebudu, že relační databáze se hodí na všechno (např. fulltext postavený pouze nad relačním modelem by byl značně neefektivní). Na druhou stranu, kdyby dost dobře nepokrývaly požadavky, tak by je nikdo nepoužíval 20 let. Sám pamatuji řadu vln, z poslední doby čistě OOP nebo čistě XML databáze. Kde jsou? Zato relační databáze se rozšiřují i tam, kde bych je nečekal (SQLite). Je to o.s., který se chová evolučně.
>> [...]Pri proceduralnim pristupu zalezi vic na kvalite programatora.[...]
> Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.
SQL dokáže používat řada lidí, kteří v životě nepochopí cyklus. I bez SQL díky grafickým rozhraním relační databáze dokáží používat amatéři (někdy ke své škodě, někdy k užitku).
>> [...]Pri neproceduralnim zas na kvalite implementace. Kdyby nebylo SQL, tak by jeste databaze programovalo par silencu hrozne draho a ostatni by si o nich vykladali, jaky ze to jsou borci. Diky SQL se staly databaze beznou zalezitosti. [...]
> ?? - databaze programuje prece i nadale par silencu a ostatni si o nich mysli ze jsou borci. Minite databazove aplikace?
Kolik aplikací vyjma her není postaveno nad databázemi. A kolik z těch databází není relačních? Je mi znám fakt, že největší db světa Google není relační :-)
> Moje poznamka se netykala ani tak toho konkretniho problemu s analyzatorem, spise jsme chtel poukazat na to, jaky obrovsky aparat se kolem tohoto modelu vybudoval. Vas clanek je jednim z mnoha milionu, ktery se zabyva s nejakou castecnou problematikou.(src:internet,diskuze k databazim) A diskuze zde to take nadherne potvrzuje. Jeden je pro hinty, druhy je v postgresql nechce videt, treti uz s nimi pracoval, ale jen pod Oracle a nyni uz chybi, aby rekl ze to bylo ve verzi 9.1.x.7, rel.12 a ze v te verzi 10.0.1.3 rell.xxx je to zase trochu vylepsene s tim, ze zase zmenili ty subselecty ... apod.
Co je na tom zvláštního. Buďto začínám od nuly a napíší si aplikaci přesně podle mého gusta, nebo se smířím s určitou neefektivitou a používám knihovny. Mercedes má mnohem větší spotřebu než kolo. Potom, ten aparát se vyvíjí 20 let, za tu dobu se napsala hromada kódu, objevily se nové metody, je k dispozici silnější hw, takže co před 10 lety se dalo řešit teoreticky se teď dá řešit prakticky. Změnila se architektura, od zámků se přechází k MGA. Roztříštěnost to samozřejmě je. Každá firma vychází z jiného prostředí, má jinou filozofii, jiné cílové zákazníky, jiné požadavky, jiné cíle. Což je jenom důsledek, že tento model žije.
Kdyby předrelační modely měly tutéž životaschopnost, a věnovala se jim tolik pozornosti, tak produkty s touto filozofií budou stejně různorodé. To, že jsou na okraji zájmů má nějaký důvod.
> To podstatne je, (bohuzel), ze den ma jen 24 hodin(src:ustav pro miry a vahy). A budto v tomto case bojuji s problemy, ktere mi pred nohy hodil nejaky model, nebo se venuji problemum zakazniku.(src:polemika :-))
Naprosto souhlasím. A proto musím napřed technologii, kterou používám rozumět. Žádný sw. se nesmí znásilňovat, tj. používat hloupě na nevhodném místě, jelikož to jinak končí průserem. Řada problémů je zděděných. Pokud někdo přeportoval Cobolovskou aplikaci do SQL 1:1, a myslel si, že to bude fungovat, tak pravděpodobně všem dalším dost zkomplikoval život. Každou techologie chce svoje. Uvedu příklad. Celá generace programátorů vyrostla na FoxPro. V okažiku, kdy začali portovat svoje aplikace na SQL, měli hromadu problémů. Problém nebyl v SQL nebo ve FoxPro. Problém byl v lidech, kteří nepochopili ze začátku principy SQL. SQL učím a vím, že je mnohem obtížnější čit programátory než amatéry, kteří nic nevědí o procedurálním programování. -
JoHnY (neregistrovaný)Musim reagovat na vas uplne posledni odstavec. Mam potvrzeni z mnohem pozdejsi doby nez FoxPro(nastupil jsem na zastavce, kde foxko definitivne vyhodili z vlaku).
Uz nekolikrat se mi overilo, ze lide kteri jsou dobri programatori vetsinou relacni databaze prilis nemyluji. Dobre rozumi algoritmum ..., ale uvazovani v relacich je jim z nejakeho duvodu nepohodlne.
Programatori zacatecnici maji casto tendence pouzivat SQL databaze jako velke vicerozmerne pole a s daty se prat az na strane jazyka(take jsem tim trpel a ne malo). Uz jsem par zacatecniku vydesil tim, ze jsem jejich databazi naplnil "odpovidajicim" vzorkem o nekolika desitcha tisic zaznamu a potom jim ukazal spotrebu pameti a rychlost jejich mileho programu. Mam z toho vzdy skodolibou radost, asi z duvodu, ze jsem podobne kraviny delal taky. Zkratka casto maji pocit, ze vsechno musi naprogramovat, a pritom staci jen rict SQL serveru a ten udela drinu za ne, navic rychle a bez memory leaku nebo odpornyho osetrovani vyjimek :)
Nejsem zadny super programator(nejsem na to dostatecny blazen - C++ pozitivni prominou ;) ), ani neovladam nijak bravurne SQL, ale na tekuty chleba ke studiu to staci s prehledem :) -
honza (neregistrovaný)uf ...
nemohu se ubranit, ale nejak citim v odpovedich nejaky rozpor. Na jedne strane to bylo drive vsechno strasne obtizne a dnes je to otazka nekolika minut, ale ti lide, kteri by to meli delat tu nejak nejsou, SQL nechapou, musi byt horem dolem skoleni, nez se pusti po tom skoleni k databazi, tak ta musi byt dobre zajistena, rada jich pouziva databazi jako velke pole atd.
Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat.
A budme uprimni, kdyby mel nekdo vedle sve prace pochopit, co se za db-navrhem skryva, tak muze jit z fleku delat toho analytika. A jak by to take mel pochopit, ve vasich prispevcich to stoji - ani lide z oboru to nechapou - ale co to je za model, ktery 1/2 lidi nechape?
Ptate se, proc je to rozsirene - inu myslim, ze se na tom da prave pekne vydelavat. Napr vy si privydelavate skolenim. Co by jste skolil u ISAMU? Rekl by jste, ze programator prske do nejakeho pole udaj, podle ktereho chce hledat (=WHERE) a ve smycce se pta(NEXT, PREV), jestli se mu to, co se naslo libi. Tim je cely model vysvetlen. To by jste si asi mnoho nevydelal.
Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa. -
okbob (neregistrovaný)> nemohu se ubranit, ale nejak citim v odpovedich nejaky rozpor. Na jedne strane to bylo drive vsechno strasne obtizne a dnes je to otazka nekolika minut, ale ti lide, kteri by to meli delat tu nejak nejsou, SQL nechapou, musi byt horem dolem skoleni, nez se pusti po tom skoleni k databazi, tak ta musi byt dobre zajistena, rada jich pouziva databazi jako velke pole atd.
Pokud nepochopite zaklady C nenapisete krome hello zadnou dalsi aplikaci (C povazuji za nejjednodussi jazyk). Proc se pouziv neefektivni java nebo C++, kterou se musim dele ucit. Protoze ve vysledku prinasi urcite pohodli.
> A budme uprimni, kdyby mel nekdo vedle sve prace pochopit, co se za db-navrhem skryva, tak muze jit z fleku delat toho analytika. A jak by to take mel pochopit, ve vasich prispevcich to stoji - ani lide z oboru to nechapou - ale co to je za model, ktery 1/2 lidi nechape?
Pokud programator nerozumi obsahu, tak jak to muze dopadnout? Problem neni v SQL.
> Ptate se, proc je to rozsirene - inu myslim, ze se na tom da prave pekne vydelavat. Napr vy si privydelavate skolenim. Co by jste skolil u ISAMU? Rekl by jste, ze programator prske do nejakeho pole udaj, podle ktereho chce hledat (=WHERE) a ve smycce se pta(NEXT, PREV), jestli se mu to, co se naslo libi. Tim je cely model vysvetlen. To by jste si asi mnoho nevydelal.
Vzpominam si na celkem draha skoleni Btree. FoxPro nas ucili cely jeden semestr. V accessu jsme prechazeli na SQL naprosto spontalne, protoze nam umoznovalo o dost citelnejsi zapis kodu. Nemohu souhlasit.
> Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa.
Nejsou ale budou. Stare generace vymrou, jako cobolisti, rplisti a jim podobni. Ta fora signalizuji neco jineh. Ze programatori jsou lina banda neochotna premyslet, kdyz maji po ruce google nebo konference. -
mys elf (neregistrovaný)>> Jeste jednou, souhlasim s tim, ze ti lide, kteri by to meli pouzivat tu NEJSOU. Ani tisice skoleni to nezmakla. Plna databazova-fora stupinich dotazu na primitivni selecty to potvrzuji. A to je jen jeden z duvodu, pros si myslim, ze je ten model katastrofa.
>Nejsou ale budou. Stare generace vymrou, jako cobolisti, rplisti a jim podobni. Ta fora signalizuji neco jineh. Ze programatori jsou lina banda neochotna premyslet, kdyz maji po ruce google nebo konference.
Myslím, že autor měl na mysli "pokročilé uživatele", tedy typické uživatele Excelu a ne programátory. Je fakt, že představa, že středoškolák před důchodem bude efektivně používat složitější SELECTy je dost odvážná, na druhou stranu mu lze díky SQL snadno ušít nástroj na míru, který mu dotaz sestaví z naklikaných parametrů (a pošle na server a zobrazí výsledky). -
honza (neregistrovaný)[...]na druhou stranu mu lze díky SQL snadno ušít nástroj na míru, který mu dotaz sestaví z naklikaných parametrů [...]
ta otazka softwaroveho inzenyrstvi zde je: KDO MU TO SESTAVI ???
- udela to pan Stehule ...(pojede do Tramtarie to nekomu sestavit)
- udela to kolega, ktery se tak dobre vyzna v te materializaci a nested loopech?
- udelate to vy ?
- udelam to ja ?
Ne, v 99% vsech pripadu se nebude dit vubec nic, protoze zde neni v patricnem okamziku ten, KTERY BY SESTAVIL. Ekonomicky je to nemozne. -
> Ne, v 99% vsech pripadu se nebude dit vubec nic, protoze zde neni v patricnem okamziku ten, KTERY BY SESTAVIL. Ekonomicky je to nemozne.
Ale je to mozne. Je rozdil jestli u nekoho programuji, nebo sestavuji SQL. A skutecne, at tomu verite nebo ne, lze neprogramatory naucit SQL. To, ze nevidi do vnitrnosti a nesestavi SQL prikaz absolutne efektivne, je v 99% jedno. Pokud jsou nastavene rozumne limity, tak nemaji co pokazit. Pokud narazi, tak si nekoho najdou, kdo jim pomuze. -
Makovec (neregistrovaný)souhlasím s Vámi. Pracoval jsem před lety na balíku účetního a personalistického software pro velké a střední podniky, a uživatelé (tj. účetní a personalisté) si měli možnost sami vytvářet a upravovat sestavy založené na SQL, a po zaškolení to vesměs dokázali (jó komplexní věci a nebo optimalizaci dotazu který byl opravdu příliš pomalý si dokoupili - a nebo jim pomohli jejich IT všeumělové - ale to bylo odhaduji pár procent případů).
Dokonce byla (je) tato možnost vítanou součástí a pro některé důležitou konkurenční výhodou uvedeného software. -
bbubla (neregistrovaný)"Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat."
Jsem uživtelem jedné databáze, kterou tvoří jeden čaroděj již sedmým rokem. Je stejného názoru jako byl tento.
Skladník, dispečerka nebo obchodník s železe si musí vydělat nejen na sebe, svou firmu. Nemohou tedy bádat nad tajemstvím SQL. Na to má najmuto a platí toho čaroděje, který si myslí, že si to uživatel přece dodělá.
Vaši uživatelé jsou placeni za jinou práci a musí uživit i Vás. Mylete na to.
Bbubbla, trochu zběhlejší BFU -
bbubla (neregistrovaný)"Nerikam to ustepacne, bohuzel jsme si ve firme take mysleli, ze aspon ty reporty si udelaji ti uzivatele sami, kdyz uz je tu ten standard. Chyby lavky, sef nakupu nas hnal okamzite az k vedeni, ze on a ani jeho podrizeni se nebudou nic ucit, oni jsou tu od nakupu. Znam samozrejme radu instituci (vesmes statnich), kde maji zamestnanci cas na hrani, ale u nasich zakazniku (vyrobni firmy) to nemohu pozorovat."
Jsem uživtelem jedné databáze, kterou tvoří jeden čaroděj již sedmým rokem. Je stejného názoru jako byl tento.
Skladník, dispečerka nebo obchodník s železe si musí vydělat nejen na sebe, svou firmu. Nemohou tedy bádat nad tajemstvím SQL. Na to má najmuto a platí toho čaroděje, který si myslí, že si to uživatel přece dodělá.
Vaši uživatelé jsou placeni za jinou práci a musí uživit i Vás. Mylete na to.
Bbubbla, trochu zběhlejší BFU -
mka (neregistrovaný)[...]Na kvalite programatora zavisi vzdy, koeficient je podle "pesimistickych" odhadu
1:30 (src:Helmut Balzert), podle "optimistickych" 1:1000 (src:software factories). Chci rici, ze jestlize zacneme do cele problematiky tahat (programatorskou) kvalitu lidi, tak toho muzeme hned nechat, nebot rozptyl tech kvalit premlati radove vsechny ostatni rozdily.[...]
Prave naopak, je potreba pocitat s tim, ze dobrych programatoru je hodne malo a tezko se hledaji. Takze kdyz pouziju relacni databazi (ktera je odladena, otestovana a praxi proverena), tak vim, ze vyuziju praci a talent tech hodne dobrych programatoru, kteri ji napsali. Naopak, kdyz si to budu programovat sam, nebo to nejakemu programatorovi zadam, bude to stat vic prace a navic dost riskuju, ze to dopadne hur. A pokud uz bych byl tak dobry (nebo mel tak dobreho programatora), ktery by to byl schopen napsat lepe, je zase mrhani talentu programovat neco, co jde vyresit neproceduralne nekolika SQL dotazy (byt treba z hlediska naroku na strojoveho cas o neco mene efektivne). -
mys elf (neregistrovaný)Nejde jenom o tohle. Když budu třeba mít rozumný E-R model databáze, tak i méně chápavému programátorovi poměrně snadno dojde, jak jsou data v systému uspořádaná. A kolem relačního modelu existuje vcelku dost propracovaná teorie (normální formy apod.) a vývoj jde stejně cestou používání standardních komponent, metodologií, formálních specifikací (UML, návrhové vzory apod.). Jenom tak se dají větší projekty držet pohromadě s rozumným úsilím. Na genialitu superprogramátorů, kteří umějí opravovat operační systém v hexakódu se spoléhat moc nedá.
-
dvh (neregistrovaný)Ahoj. Zacinam s postgresom a mam dotaz na logovanie dlho trvajucich selektov. Robil som predtym v informixe (5.0) a tam nieco take nebolo. Pritom 30 minutove selekty tam boli pomerne bezne. Riesil som to cca tak ze som spustal pravidelne vypis procesov (ps) hladal som db klientov (grep sqlturbo) a ak bezali dlhsie ako minutu tak som si zapisoval meno uzivatela do logu. Da sa to robit nejak inteligentnejsie v PostreSQL ? Ak ano tak ako? Vdaka.
-
V pg se dá dělat inteligentněji. Nastavte si log_min_duration_statement = 1000 nebo jinou hodnotu (v ms) v postgresql.conf. Celkem dost dobrý analyzátor logů je na http://pgfouine.projects.postgresql.org/
-
Moc pěkný článek,
trošku bych ho využil a zeptal se: mám poměrně složitou funkci (několik smyček, dotazy, updaty), je dosti pomalá. Zkontroloval jsem, zda jsou u všech WHERE a ORDER sloupců indexy, možná je úzké hrdlo v tom, že INSERT a UPDATE dotazy se generují za běhu.
Nicméně k otázce, zkusil jsem EXPLAIN SELECT MOJE_FUNKCE() a nic. Předpokládám, že EXPLAIN lze použít jen u funkcí, které vracejí tabulku (moje nic nevrací).
Jakým způsobem bych mohl snadno zjistit, co je brzdou dané funkce?
ps - tlačítka ODESLAT a ZOBRAZIT NÁHLED nefungují v Konqueroru, to je ale ostuda... -
Pavel Stehule (neregistrovaný)pro explain jsou funkce cernou skrinkou. Zkontroloval bych vsechny SQL prikazy. U prepared statements se nemusi chytit index, jelikoz se vytvari plan v okamziku, kdy neznam parametry. Tudiz natvrdo zapsany SQL prikaz muze byt efektivnejsi nez predzpracovany, a pak nezbyde nez pouzit EXECUTE. Urcite funguje (minimum +/- 8.0) FOR IN EXPLAIN SELECT ... LOOP (vypis provadeciho planu je tabulka). Jinak se podivejte, jestli muzete pouzit
#debug_print_parse = off #debug_print_rewritten = off #debug_print_plan = off #debug_pretty_print = off
nikdy jsem to netestoval. Predpokladam, ze to je k tomu na co se ptate, -
Tomas (neregistrovaný)
Flatening velmi oceňuji jako optimalizační techniku. Chtěl bych se zeptat zda PostgreSQL umí i něco jako deflattenig. Například:
select neco from A join B on substring(A.a from 2 for 2) = substring(B.b from 3 for 2)
a po úpravě optimizerem by bylo vyhodnoceno jako
select neco from ( select A.*, substring(A.a from 2 for 2) as join_key from A ) as AA join ( select B.*, substring(B.a from 3 for 2) as join_key from B ) as BB on AA.join_key = BB.join_key
První přístup vyprodukuje product join (nested loops), druhý by měl skončit u materializace subselectů a hash joinu. Pokud jsou tabulky A a B velké, pak druhý přístup by měl vést ke zrychlení několika řádů.
Lze nějak sbírat vícesloupcové statistiky (statistiky přes více sloupců než jeden)? V manuálu jsem to nenašel.
Předem díky za případné odpovědi.
Tomáš
-
> Flatening velmi oceňuji jako optimalizační techniku. Chtěl bych se zeptat zda PostgreSQL umí i něco jako deflattenig. Například: ...
Toto a dalsi divociny jedine rucne. Na to aby se pouzil hash join stejne musite mit dost pameti na hashovaci tabulky. Mozna to bude fungovat, ale predpokladam, ze pro extremni tabulky se hash join nepouzije. Tohle bych spis resil docasnym funkcionalnim indexem.
> Lze nějak sbírat vícesloupcové statistiky (statistiky přes více sloupců než jeden)? V manuálu jsem to nenašel.
Nelze. Pracuje se pouze s korelaci mezi sloupci. -
Marek Jakub (neregistrovaný)Hash join je v tomto případě velice efektivní i v případě velkých tabulek. V mém případě jsem použil 2 tabulky o cca 800000 záznamů a dotaz trval pouze 145s
SQL> select count(*) from aa
2 ;
COUNT(*)
----------
834471
SQL> select count(*) from bb;
COUNT(*)
----------
834768
SQL> select count(*) from aa, bb where substr(aa.OBJECT_NAME,2,3) = substr(bb.OBJECT_NAME, 3,3);
COUNT(*)
----------
444161718
Přičemž provedeno bylo pouze 5346 diskových operací spojených se čtením tabulek a 7397read a 4350write operací spojených s hashováním a výsledek měl 400mio záznamů. Obě tabulky zabírají cca 2700 bloků o 8k. Test jsem prováděl na mém nb AMD Turion 64 1.6Ghz a 1G paměti, ale pro DB bylo definováno cca 270Mb.
Rows Row Source Operation
------- ---------------------------------------------------
1 SORT AGGREGATE (cr=5346 pr=7397 pw=4350 time=145033645 us)
444161718 HASH JOIN (cr=5346 pr=7397 pw=4350 time=891859549 us)
834768 TABLE ACCESS FULL BB (cr=2674 pr=1885 pw=0 time=1686868 us)
834471 TABLE ACCESS FULL AA (cr=2672 pr=1162 pw=0 time=1669039 us) -
Marek Jakub (neregistrovaný)Máte skutečně ověřeno, že Váš případ skutečně bude skutečně vyhodnocen nested loopem? Protože prakticky se nijak neliší od joinu dvou tabulek, podle neindexovaných atributů.
Sice neznám pg, ale v ORACLU jsem si jist, že pokud nepoužijete funkcionální indexy, tak tento případ bude téměř jistě vyhodnocen hash joinem. Testoval jsem to na tabulkách různých velikostí a nested loop jsem nodostal ani náhodou.
Proto se mi nechce moc věřit, že by optimizer pg tento podle mého názoru vcelku primitivní případ řešil nested loopem.
Materializace je v tomto případě neefektivní, protože pokud ty tabulky jsou velké a vy říkáte, že ano, tak dočasně vytváří v podstatě kopii obou tabulek, přičemž mu nic nebrání provádět hash join podle umělých atributů vypočtených za chodu.
Nicméně, pokud máte ověřeno, že to skutečně provádí nested loopem, pořád nevěřím. Můžete tuto chybu snadno vyřešit právě pomocí flatteningu konstrukcí
select neco from ( select A.*, substring(A.a from 2 for 2) as join_key from A OFFSET 0 ) as AA join ( select B.*, substring(B.a from 3 for 2) as join_key from B OFFSET 0) as BB on AA.join_key = BB.join_key
