Gisugyot ko nga basahon nimo ang transcript sa sayo nga taho ni Vladimir Sitnikov sa 2016 nga "PostgreSQL ug JDBC nagpuga sa tanan nga juice"
Maayong hapon Ako si Vladimir Sitnikov. Nagtrabaho ko sa NetCracker sulod sa 10 ka tuig. Ug kasagaran ako sa pagka-produktibo. Ang tanan nga may kalabutan sa Java, ang tanan nga may kalabutan sa SQL mao ang akong gihigugma.
Ug karon akong hisgutan kung unsa ang among nasugatan sa kompanya sa dihang nagsugod kami sa paggamit sa PostgreSQL ingon usa ka database server. Ug kasagaran kami nagtrabaho sa Java. Apan ang akong isulti kanimo karon dili lang bahin sa Java. Ingon sa gipakita sa praktis, kini mahitabo usab sa ubang mga pinulongan.
Maghisgot kita:
- mahitungod sa data sampling.
- Mahitungod sa pagtipig sa datos.
- Ug mahitungod usab sa performance.
- Ug mahitungod sa mga rake sa ilawom sa tubig nga gilubong didto.
Magsugod ta sa usa ka yano nga pangutana. Nagpili kami usa ka laray gikan sa lamesa base sa panguna nga yawe.
Ang database nahimutang sa parehas nga host. Ug kining tanan nga pagpanguma nagkinahanglan og 20 milliseconds.
Kini nga 20 milliseconds daghan. Kung ikaw adunay 100 nga ingon nga mga hangyo, nan mogahin ka ug oras matag segundo sa pag-scroll sa kini nga mga hangyo, i.e. nag-usik kami sa oras.
Dili kami ganahan nga buhaton kini ug tan-awon kung unsa ang gitanyag kanamo sa base alang niini. Ang database nagtanyag kanamo duha ka kapilian alang sa pagpatuman sa mga pangutana.
Ang una nga kapilian usa ka yano nga hangyo. Unsay maayo niini? Ang kamatuoran nga among gikuha ug gipadala, ug wala na.
Ang database usab adunay usa ka advanced nga pangutana, nga labi ka malisud, apan labi ka magamit. Mahimo ka nga maglainlain nga magpadala usa ka hangyo alang sa pag-parse, pagpatuman, variable nga pagbugkos, ug uban pa.
Ang sobrang gipalapdan nga pangutana usa ka butang nga dili namon hisgutan sa karon nga taho. Kita, tingali, gusto sa usa ka butang gikan sa database ug adunay usa ka wish list nga naporma sa usa ka porma, i.e. mao kini ang atong gusto, apan kini imposible karon ug sa sunod nga tuig. Mao nga girekord lang namo kini ug maglibot-libot kami sa pag-uyog sa mga nag-unang tawo.
Ug ang atong mahimo mao ang yano nga pangutana ug gipalapdan nga pangutana.
Unsa ang espesyal sa matag pamaagi?
Ang usa ka yano nga pangutana maayo alang sa usa ka higayon nga pagpatuman. Sa dihang nahuman ug nakalimtan. Ug ang problema mao nga wala kini nagsuporta sa binary data format, i.e. kini dili angay alang sa pipila ka mga high-performance nga sistema.
Gipadako nga pangutana - nagtugot kanimo nga makadaginot sa oras sa pag-parse. Mao kini ang among gibuhat ug nagsugod sa paggamit. Nakatabang gyud kini kanamo. Adunay dili lamang savings sa parsing. Adunay mga savings sa pagbalhin sa data. Ang pagbalhin sa datos sa binary format mas episyente.
Magpadayon ta sa pagpraktis. Kini ang hitsura sa usa ka tipikal nga aplikasyon. Mahimo kini nga Java, ug uban pa.
Naghimo kami og pahayag. Gipatuman ang mando. Gibuhat nga suod. Asa ang sayop dinhi? Unsay problema? Walay problema. Mao kini ang giingon sa tanang libro. Ingon niini ang kinahanglan isulat. Kung gusto nimo ang labing taas nga pasundayag, pagsulat sama niini.
Apan gipakita sa praktis nga dili kini molihok. Ngano man? Kay naa tay "close" nga pamaagi. Ug kung buhaton naton kini, gikan sa punto sa database nga kini nahimo nga sama sa usa ka hinabako nga nagtrabaho sa usa ka database. Nakaingon mi nga "PARSE EXECUTE DEALLOCATE".
Ngano nga kining tanan nga dugang nga paghimo ug pagdiskarga sa mga pahayag? Walay nagkinahanglan kanila. Apan ang kasagarang mahitabo sa PreparedStatements mao nga kung atong isira sila, ilang isira ang tanan sa database. Dili kini ang atong gusto.
Gusto namon, sama sa himsog nga mga tawo, nga magtrabaho kauban ang base. Among gikuha ug giandam ang among pahayag kausa, unya among gipatuman kini sa makadaghang higayon. Sa tinuud, daghang mga higayon - kini usa ka higayon sa tibuuk nga kinabuhi sa mga aplikasyon - na-parse na sila. Ug gigamit namon ang parehas nga pahayag id sa lainlaing mga REST. Kini ang atong tumong.
Unsaon nato pagkab-ot niini?
Kini yano kaayo - dili kinahanglan nga tapuson ang mga pahayag. Gisulat namo kini sama niini: "pag-andam" "pagpatuman".
Kung maglunsad kita og usa ka butang nga sama niini, nan klaro nga adunay moawas sa usa ka dapit. Kung dili kini klaro, mahimo nimong sulayan kini. Magsulat kita og usa ka benchmark nga naggamit niining yano nga pamaagi. Paghimo og pahayag. Gilunsad namo kini sa pipila ka bersyon sa drayber ug nakita nga kini daling nahagsa uban sa pagkawala sa tanang panumduman nga anaa niini.
Klaro nga ang maong mga sayop daling matul-id. Dili ko maghisgot bahin nila. Apan isulti ko nga ang bag-ong bersyon molihok nga labi ka paspas. Ang pamaagi hungog, apan sa gihapon.
Unsaon pagtrabaho sa husto? Unsa ang kinahanglan natong buhaton alang niini?
Sa tinuud, ang mga aplikasyon kanunay nga nagsira sa mga pahayag. Sa tanan nga mga libro giingon nila nga isira kini, kung dili ang panumduman motulo.
Ug wala mahibal-an sa PostgreSQL kung giunsa ang pag-cache sa mga pangutana. Kinahanglan nga ang matag sesyon maghimo niini nga cache alang sa iyang kaugalingon.
Ug dili usab kami gusto nga mag-usik ug oras sa pag-parse.
Ug sama sa naandan naa mi duha ka kapilian.
Ang una nga kapilian mao ang pagkuha niini ug isulti nga iputos ang tanan sa PgSQL. Adunay usa ka cache didto. Gitago niini ang tanan. Kini mahimong maayo. Nakita namo kini. Kami adunay 100500 nga mga hangyo. Dili mogana. Dili kami mouyon sa paghimo sa mga hangyo ngadto sa mga pamaagi nga mano-mano. Dili dili.
Kami adunay ikaduha nga kapilian - kuhaa kini ug putla kini sa among kaugalingon. Giablihan namo ang mga tinubdan ug nagsugod sa pagputol. Among nakita ug nakita. Kini nahimo nga kini dili kaayo lisud nga buhaton.
Kini nagpakita sa Agosto 2015. Karon adunay mas modernong bersyon. Ug ang tanan maayo. Naglihok kini nga maayo nga wala kami magbag-o bisan unsa sa aplikasyon. Ug mihunong pa gani kami sa paghunahuna sa direksyon sa PgSQL, i.e. igo na kini alang kanamo aron makunhuran ang tanang gasto sa overhead ngadto sa halos zero.
Tungod niini, ang mga pahayag nga giandam sa server gi-aktibo sa ika-5 nga pagpatuman aron malikayan ang pag-usik sa memorya sa database sa matag usa ka higayon nga hangyo.
Mahimong mangutana ka - asa ang mga numero? Unsa imong makuha? Ug dinhi dili ako mohatag og mga numero, tungod kay ang matag hangyo adunay iyang kaugalingon.
Ang among mga pangutana mao nga migugol kami ug mga 20 milliseconds sa pag-parse sa mga pangutana sa OLTP. Adunay 0,5 milliseconds para sa execution, 20 milliseconds para sa parsing. Paghangyo - 10 KiB nga teksto, 170 ka linya sa plano. Kini usa ka OLTP nga hangyo. Nangayo kini og 1, 5, 10 ka linya, usahay labaw pa.
Apan dili namo gusto nga usikan ang 20 milliseconds. Gipaubos namo kini sa 0. Nindot ang tanan.
Unsa ang imong makuha gikan dinhi? Kung ikaw adunay Java, unya imong kuhaon ang modernong bersyon sa drayber ug magmaya.
Kung nagsulti ka ug lahi nga lengguwahe, unya hunahunaa - tingali kinahanglan nimo usab kini? Tungod kay gikan sa punto sa panglantaw sa katapusan nga pinulongan, pananglitan, kung ang PL 8 o ikaw adunay LibPQ, nan kini dili klaro kanimo nga ikaw naggugol ug panahon dili sa pagpatay, sa pag-parse, ug kini angay nga susihon. Giunsa? Ang tanan libre.
Gawas nga adunay mga sayup ug pipila ka mga peculiarities. Ug kita maghisgot mahitungod kanila karon. Kadaghanan niini mahitungod sa arkeolohiya sa industriya, mahitungod sa kung unsa ang among nakit-an, kung unsa ang among nakit-an.
Kung ang hangyo nahimo nga dinamikong. Kini mahitabo. Adunay usa nga nagtapot sa mga kuwerdas, nga miresulta sa usa ka pangutana sa SQL.
Nganong daotan siya? Malain kay kada tungtong namo sa lahi nga kuwerdas.
Ug ang hashCode niining lahi nga hilo kinahanglan nga basahon pag-usab. Kini usa ka buluhaton sa CPU - ang pagpangita sa usa ka taas nga teksto sa hangyo bisan sa usa ka naglungtad nga hash dili kaayo kadali. Busa, ang konklusyon yano - ayaw paghimo og mga hangyo. Tipigi kini sa usa ka variable. Ug pagmaya.
Sunod nga problema. Importante ang mga tipo sa datos. Adunay mga ORM nga nag-ingon nga dili igsapayan kung unsang klase sa NULL ang naa, pabay-i nga adunay usa ka matang. Kung Int, nan giingon namon ang setInt. Ug kung NULL, nan himoa nga kini kanunay nga VARCHAR. Ug unsa ang kalainan niini sa katapusan kung unsa ang NULL? Ang database mismo makasabut sa tanan. Ug kini nga litrato dili molihok.
Sa praktis, ang database wala gyud magtagad. Kung giingon nimo sa unang higayon nga kini usa ka numero, ug sa ikaduha nga higayon nga giingon nimo nga kini usa ka VARCHAR, nan imposible nga magamit pag-usab ang mga pahayag nga giandam sa Server. Ug sa kini nga kaso, kinahanglan naton nga himuon pag-usab ang atong pahayag.
Kung nagpatuman ka sa parehas nga pangutana, siguroha nga ang mga tipo sa datos sa imong kolum dili malibog. Kinahanglan nimong bantayan ang NULL. Kini usa ka kasagarang sayup nga among naangkon pagkahuman nagsugod kami sa paggamit sa PreparedStatements
Okay, gi-on. Basin ilang gikuha ang driver. Ug ang pagka-produktibo nahulog. Ang mga butang nahimong dili maayo.
Sa unsang paagi kini mahitabo? Kini ba usa ka bug o usa ka bahin? Ikasubo, dili posible nga masabtan kung kini usa ka bug o usa ka bahin. Apan adunay usa ka yano kaayo nga senaryo alang sa pag-reproduce niini nga problema. Wala niya damha nga gi-ambush mi niya. Ug kini naglangkob sa sampling literal gikan sa usa ka lamesa. Kami, siyempre, adunay daghang ingon nga mga hangyo. Ingon sa usa ka lagda, sila naglakip sa duha o tulo ka mga lamesa, apan adunay ingon nga playback nga senaryo. Kuhaa ang bisan unsang bersyon gikan sa imong database ug dulaa kini.
Ang punto mao nga kita adunay duha ka mga kolum, ang matag usa niini gi-index. Adunay usa ka milyon nga mga laray sa usa ka NULL nga kolum. Ug ang ikaduhang kolum adunay 20 lang ka linya. Kung nag-execute kami nga walaβy bound variable, maayo ang tanan.
Kung magsugod kita sa pagpatuman sa mga bound variable, i.e. atong ipatuman ang "?" o "$1" alang sa among hangyo, unsa ang among makuha?
Ang una nga pagpatay sama sa gipaabut. Ang ikaduha mas paspas. Adunay gi-cache. Ikatulo, ikaupat, ikalima. Unya bang - ug usa ka butang nga sama niana. Ug ang labing daotan nga butang mao nga kini mahitabo sa ikaunom nga pagpatay. Kinsa ang nahibal-an nga kinahanglan nga buhaton ang eksaktong unom ka pagpatay aron masabtan kung unsa ang aktwal nga plano sa pagpatay?
Kinsa ang sad-an? Unsay nahitabo? Ang database naglangkob sa pag-optimize. Ug kini daw na-optimize alang sa generic nga kaso. Ug, sa ingon, sugod sa usa ka punto, siya mibalhin sa usa ka generic nga plano, nga, sa kasubo, mahimong lahi. Mahimong magkaparehas ra kini, o mahimong lahi. Ug adunay usa ka matang sa kantidad sa threshold nga nagdala sa kini nga pamatasan.
Unsay imong mahimo niini? Dinhi, siyempre, mas lisud ang paghunahuna sa bisan unsa. Adunay usa ka yano nga solusyon nga among gigamit. Kini ang +0, OFFSET 0. Sigurado nga nahibal-an nimo ang ingon nga mga solusyon. Gikuha lang namo kini ug gidugang ang "+0" sa hangyo ug maayo ang tanan. Ipakita ko nimo unya.
Ug adunay laing kapilian - tan-awa pag-ayo ang mga plano. Ang developer kinahanglan dili lamang sa pagsulat sa usa ka hangyo, apan usab sa pag-ingon "ipasabut analisa" 6 ka beses. Kung kini 5, dili kini molihok.
Ug adunay usa ka ikatulo nga kapilian - pagsulat sa usa ka sulat sa pgsql-hacker. Gisulat ko, bisan pa, dili pa klaro kung kini usa ka bug o usa ka bahin.
Samtang naghunahuna kita kung kini ba usa ka bug o usa ka bahin, ayohon nato kini. Atong kuhaon ang atong hangyo ug idugang ang "+0". Maayo ra ang tanan. Duha ka simbolo ug dili nimo kinahanglan nga maghunahuna kung giunsa kini o kung unsa kini. Simple kaayo. Gidili lang namo ang database sa paggamit ug index niini nga column. Wala kami usa ka indeks sa kolum nga "+0" ug mao kana, ang database wala mogamit sa indeks, ang tanan maayo.
Kini ang lagda sa 6 ipasabut. Karon sa kasamtangan nga mga bersyon kinahanglan nimo nga buhaton kini 6 ka beses kung ikaw adunay mga bound variable. Kung wala kay bound variables, mao kini ang among buhaton. Ug sa katapusan mao gayud kini nga hangyo nga napakyas. Dili kini usa ka malisud nga butang.
Morag, unsa kadaghan ang mahimo? Bug diri, bug didto. Sa pagkatinuod, ang bug anaa bisan asa.
Atong tan-awon pag-ayo. Pananglitan, kami adunay duha ka eskema. Scheme A nga adunay lamesa S ug diagram B nga adunay lamesa S. Pangutana - pagpili og datos gikan sa usa ka lamesa. Unsa ang atong mabatonan niini nga kaso? Kita adunay usa ka sayop. Mabatonan nato ang tanan sa ibabaw. Ang lagda mao - ang usa ka bug anaa bisan asa, maangkon nato ang tanan sa ibabaw.
Karon ang pangutana mao: "Ngano?" Morag adunay dokumentasyon nga kung kita adunay usa ka schema, nan adunay usa ka variable nga "search_path" nga nagsulti kanato kung asa pangitaon ang lamesa. Murag naay variable.
Unsay problema? Ang problema mao nga ang mga pahayag nga giandam sa server wala magduda nga ang search_path mahimong usbon sa usa ka tawo. Kini nga bili nagpabilin, ingon nga kini, kanunay alang sa database. Ug ang pipila ka mga bahin mahimong dili makakuha og bag-ong mga kahulugan.
Siyempre, kini nagdepende sa bersyon nga imong gisulayan. Depende kung unsa ka seryoso ang pagkalainlain sa imong mga lamesa. Ug ang bersyon 9.1 ipatuman ra ang daan nga mga pangutana. Ang mga bag-ong bersyon mahimong makadakop sa bug ug makasulti kanimo nga ikaw adunay bug.
Giunsa kini pagtratar? Adunay usa ka yano nga resipe - ayaw kini buhata. Dili kinahanglan nga usbon ang search_path samtang nagdagan ang aplikasyon. Kung magbag-o ka, mas maayo nga maghimo usa ka bag-ong koneksyon.
Mahimo nimong hisgutan, i.e. abli, hisgutan, idugang. Tingali mahimo natong kombinsihon ang mga nag-develop sa database nga kung adunay magbag-o sa usa ka kantidad, ang database kinahanglan isulti sa kliyente bahin niini: "Tan-awa, ang imong kantidad gi-update dinhi. Tingali kinahanglan nimo nga i-reset ang mga pahayag ug himuon kini pag-usab? β Karon ang database naglihok sa tago ug wala magreport sa bisan unsang paagi nga ang mga pahayag nausab sa usa ka dapit sa sulod.
Ug akong ipasiugda pag-usab - kini usa ka butang nga dili kasagaran sa Java. Makita nato ang samang butang sa PL/pgSQL one to one. Apan kini i-reproduce didto.
Atong sulayan ang pipila pa nga pagpili sa datos. Kita mopili ug mopili. Kami adunay usa ka lamesa nga adunay usa ka milyon nga mga laray. Ang matag linya usa ka kilobyte. Gibana-bana nga usa ka gigabyte nga datos. Ug kami adunay nagtrabaho nga panumduman sa Java machine nga 128 megabytes.
Kami, ingon nga girekomenda sa tanan nga mga libro, naggamit sa pagproseso sa sapa. Sa ato pa, giablihan namo ang resultaSet ug gibasa ang datos gikan didto sa hinay-hinay. Mosalir ba kini? Mahulog ba kini gikan sa panumduman? Magbasa ka ba gamay? Salig ta sa database, salig ta sa Postgres. Dili kami motuo niini. Mahulog ba kita sa OutOFMemory? Kinsa ang nakasinati sa OutOfMemory? Kinsa ang nakahimo sa pag-ayo niini pagkahuman? Adunay nakahimo sa pag-ayo niini.
Kung ikaw adunay usa ka milyon nga mga linya, dili ka makapili ug makapili. OFFSET/LIMIT gikinahanglan. Kinsa ang alang niini nga kapilian? Ug kinsa ang pabor sa pagdula sa autoCommit?
Dinhi, sama sa naandan, ang labing wala damha nga kapilian nahimo nga husto. Ug kung kalit nimo nga gipalong ang autoCommit, makatabang kini. Ngano man? Ang siyensya wala mahibalo bahin niini.
Apan pinaagi sa default, ang tanan nga mga kliyente nga nagkonektar sa usa ka database sa Postgres nagkuha sa tibuuk nga datos. Ang PgJDBC dili eksepsiyon niining bahina; kini nagpili sa tanang mga laray.
Adunay usa ka kalainan sa FetchSize nga tema, i.e. mahimo nimong isulti sa lebel sa usa ka bulag nga pahayag nga dinhi, palihug pilia ang datos sa 10, 50. Apan dili kini molihok hangtod nga imong mapatay ang autoCommit. Gipalong ang autoCommit - nagsugod kini sa pagtrabaho.
Apan ang pag-agi sa code ug setting setFetchSize bisan asa dili kombenyente. Busa, naghimo kami usa ka setting nga magsulti sa default nga kantidad alang sa tibuuk nga koneksyon.
Mao na among giingon. Ang parameter na-configure na. Ug unsay atong nakuha? Kung mopili kita og gagmay nga kantidad, kung, pananglitan, mopili kita og 10 ka laray sa usa ka higayon, nan kita adunay dako kaayo nga gasto sa overhead. Busa, kini nga kantidad kinahanglan nga ibutang sa mga usa ka gatos.
Sa tinuud, siyempre, kinahanglan nimo nga mahibal-an kung giunsa kini limitahan sa mga byte, apan ang resipe mao kini: ibutang ang defaultRowFetchSize sa sobra sa usa ka gatos ug magmalipayon.
Mopadayon kita sa pagsal-ot sa datos. Mas sayon ββββang pagsal-ot, adunay lainlaing mga kapilian. Pananglitan, INSERT, VALUES. Kini usa ka maayong kapilian. Mahimo nimong isulti ang "INSERT SELECT". Sa praktis kini mao ang sama nga butang. Walay kalainan sa performance.
Ang mga libro nag-ingon nga kinahanglan nimo nga ipatuman ang usa ka Batch nga pahayag, ang mga libro nag-ingon nga mahimo nimong ipatuman ang labi ka komplikado nga mga mando nga adunay daghang mga parentesis. Ug ang Postgres adunay nindot nga bahin - mahimo nimo ang COPY, i.e. buhata kini nga mas paspas.
Kung imong sukdon kini, makahimo ka na usab og pipila ka makapaikag nga mga diskobre. Sa unsang paagi nato gusto nga kini molihok? Gusto namon nga dili i-parse ug dili ipatuman ang wala kinahanglana nga mga mando.
Sa praktis, ang TCP wala magtugot kanamo sa pagbuhat niini. Kung ang kliyente nagkapuliki sa pagpadala sa usa ka hangyo, nan ang database wala magbasa sa mga hangyo sa pagsulay sa pagpadala kanamo og mga tubag. Ang katapusan nga resulta mao nga ang kliyente naghulat alang sa database sa pagbasa sa hangyo, ug ang database naghulat alang sa kliyente sa pagbasa sa tubag.
Ug busa napugos ang kliyente nga matag karon ug unya magpadala usa ka pakete sa pag-synchronize. Dugang nga mga interaksyon sa network, dugang nga pag-usik sa oras.
Ug kon daghan ang atong idugang kanila, mas mograbe kini. Ang drayber medyo pessimistic ug gidugang kini kanunay, mga kausa sa matag 200 ka linya, depende sa gidak-on sa mga linya, ug uban pa.
Nahitabo nga imong gitul-id ang usa lang ka linya ug ang tanan mopaspas sa 10 ka beses. Kini mahitabo. Ngano man? Sama sa naandan, ang usa ka kanunay nga sama niini gigamit na bisan diin. Ug ang kantidad nga "128" nagpasabut nga dili gamiton ang batching.
Maayo nga wala kini gilakip sa opisyal nga bersyon. Nadiskobrehan sa wala pa magsugod ang pagpagawas. Ang tanan nga mga kahulugan nga akong gihatag gibase sa modernong mga bersyon.
Atong sulayan kini. Gisukod namon ang InsertBatch nga yano. Among gisukod ang InsertBatch sa makadaghang higayon, i.e. sa samang butang, apan adunay daghang mga kantidad. Lisud nga paglihok. Dili tanan makahimo niini, apan kini usa ka yano nga lakang, labi ka dali kaysa COPY.
Mahimo nimo ang COPY.
Ug mahimo nimo kini sa mga istruktura. Ideklara ang User default type, ipasa ang array ug INSERT direkta sa lamesa.
Kung ablihan nimo ang link: pgjdbc/ubenchmsrk/InsertBatch.java, nan kini nga code naa sa GitHub. Makita nimo kung unsa nga mga hangyo ang gihimo didto. Dili igsapayan.
Among gilusad. Ug ang una nga butang nga among nahibal-an mao nga ang dili paggamit sa batch imposible. Ang tanan nga mga kapilian sa batching zero, i.e. ang oras sa pagpatuman halos zero kung itandi sa usa ka higayon nga pagpatay.
Gisulud namon ang datos. Kini usa ka yano kaayo nga lamesa. Tulo ka kolum. Ug unsa ang atong makita dinhi? Nakita namon nga ang tanan nga tulo niini nga mga kapilian halos managsama. Ug ang COPY, siyempre, mas maayo.
Kini mao ang sa diha nga kita sal-ot sa mga piraso. Sa dihang giingon namo nga usa ka VALUES value, duha ka VALUES value, tulo ka VALUES value, o among gipakita ang 10 niini nga gibulag sa comma. horizontal lang ni. 1, 2, 4, 128. Makit-an nga ang Batch Insert, nga gidrowing sa asul, mas maayo ang iyang gibati. Sa ato pa, kung mag-insert ka sa usa sa usa ka higayon o bisan kung imong i-insert ang upat sa usa ka higayon, kini mahimong doble nga maayo, tungod lang kay nag-cramm kami og gamay sa VALUES. Diyutay nga mga operasyon sa EXECUTE.
Ang paggamit sa COPY sa gagmay nga mga volume hilabihan ka dili maayo. Wala man ko magdrawing sa unang duha. Sila moadto sa langit, nga mao, kini nga mga berdeng numero alang sa COPY.
Ang COPY kinahanglang gamiton kung aduna kay labing menos usa ka gatos ka laray sa datos. Ang overhead sa pag-abli niini nga koneksyon dako. Ug, sa tinuod, wala ko nagkalot niini nga direksyon. Gi-optimize nako ang Batch, apan dili COPY.
Unsay sunod natong buhaton? Gisulayan namo kini. Nakasabut kami nga kinahanglan namon nga gamiton ang bisan unsang mga istruktura o usa ka maalamon nga bacth nga naghiusa sa daghang mga kahulugan.
Unsay angay nimong kuhaan sa report karong adlawa?
- Ang PreparedStatement mao ang among tanan. Naghatag kini og daghan alang sa pagka-produktibo. Naghimo kini usa ka dako nga flop sa ointment.
- Ug kinahanglan nimong buhaton ang EXPLAIN ANALYZE 6 ka beses.
- Ug kinahanglan namong tunawon ang OFFSET 0, ug mga limbong sama sa +0 aron matul-id ang nahabilin nga porsyento sa among problema nga mga pangutana.
Source: www.habr.com