Puoli vuotta sitten - julkinen PostgreSQL:ään.
Viime kuukausina olemme tehneet hänestä , laati yhteenvedon sen antamien suositusten perusteella... mutta mikä tärkeintä, keräsimme palautteesi ja tarkastelimme todellisia käyttötapauksia.
Ja nyt olemme valmiita kertomaan sinulle uusista ominaisuuksista, joita voit käyttää.
Tuki eri suunnitelmamuotoille
Suunnitelma lokista pyynnön mukana
Valitsemme suoraan konsolista koko lohkon riviltä alkaen Kyselyteksti, kaikilla aloilla:
Query Text: INSERT INTO dicquery_20200604 VALUES ($1.*) ON CONFLICT (query)
DO NOTHING;
Insert on dicquery_20200604 (cost=0.00..0.05 rows=1 width=52) (actual time=40.376..40.376 rows=0 loops=1)
Conflict Resolution: NOTHING
Conflict Arbiter Indexes: dicquery_20200604_pkey
Tuples Inserted: 1
Conflicting Tuples: 0
Buffers: shared hit=9 read=1 dirtied=1
-> Result (cost=0.00..0.05 rows=1 width=52) (actual time=0.001..0.001 rows=1 loops=1)
... ja heittää kaikki kopioitu suoraan suunnitelman kenttään erottamatta mitään:
Lähdössä saamme myös bonuksen purettuun suunnitelmaan konteksti-välilehti, jossa pyyntömme esitetään kaikessa loistossaan:
JSON ja YAML
EXPLAIN (ANALYZE, BUFFERS, FORMAT JSON)
SELECT * FROM pg_class;"[
{
"Plan": {
"Node Type": "Seq Scan",
"Parallel Aware": false,
"Relation Name": "pg_class",
"Alias": "pg_class",
"Startup Cost": 0.00,
"Total Cost": 1336.20,
"Plan Rows": 13804,
"Plan Width": 539,
"Actual Startup Time": 0.006,
"Actual Total Time": 1.838,
"Actual Rows": 10266,
"Actual Loops": 1,
"Shared Hit Blocks": 646,
"Shared Read Blocks": 0,
"Shared Dirtied Blocks": 0,
"Shared Written Blocks": 0,
"Local Hit Blocks": 0,
"Local Read Blocks": 0,
"Local Dirtied Blocks": 0,
"Local Written Blocks": 0,
"Temp Read Blocks": 0,
"Temp Written Blocks": 0
},
"Planning Time": 5.135,
"Triggers": [
],
"Execution Time": 2.389
}
]"Jopa ulkoisilla lainausmerkeillä, kuten pgAdmin kopioi, jopa ilman - heitämme samaan kenttään, tulos on kauneus:
Kehittynyt visualisointi
Suunnitteluaika / toteutusaika
Nyt näet paremmin, mihin ylimääräinen aika meni kyselyä suoritettaessa:
I/O-ajoitus
Joskus joutuu kohtaamaan tilanteen, jossa resurssien suhteen näyttää siltä, ettei liikaa ole luettu ja kirjoitettu, mutta toteutusaika näyttää jostain syystä olevan epäjohdonmukaisen suuri.
Se on sanottava tässä:Voi, luultavasti sillä hetkellä palvelimen levy oli liian ylikuormitettu, siksi sen lukeminen kesti niin kauan!"Mutta jotenkin se ei ole kovin tarkkaa...
Mutta se voidaan määrittää täysin luotettavasti. Tosiasia on, että PG-palvelimen määritysvaihtoehtojen joukossa on :
Ottaa käyttöön ajoitetut I/O-toiminnot. Tämä asetus on oletuksena poissa käytöstä, koska se vaatii käyttöjärjestelmän jatkuvasti kyselemään kellonaikaa, mikä voi hidastaa toimintaa merkittävästi joillakin alustoilla. Voit käyttää pg_test_timing-apuohjelmaa arvioidaksesi ajastuksen yleiskustannuksia alustallasi. I/O-tilastot voidaan saada pg_stat_tietokantanäkymästä, EXPLAIN-ulostulossa (kun BUFFERS-parametria käytetään) ja pg_stat_statements-näkymän kautta.
Tämä vaihtoehto voidaan ottaa käyttöön myös paikallisessa istunnossa:
SET track_io_timing = TRUE;No, nyt parasta on, että olemme oppineet ymmärtämään ja näyttämään nämä tiedot ottaen huomioon kaikki suorituspuun muunnokset:
Tästä näet, että 0.790 ms kokonaissuoritusajasta 0.718 ms kesti yhden sivun lukemiseen, 0.044 ms - sen kirjoittamiseen ja vain 0.028 ms käytettiin kaikkeen muuhun hyödylliseen toimintaan!
Tulevaisuus PostgreSQL 13:n kanssa
Katso täydellinen yleiskatsaus uusiin ominaisuuksiin , ja puhumme nimenomaan suunnitelmien muutoksista.
Suunnittelupuskurit
Ajastimelle allokoitujen resurssien huomioon ottaminen näkyy toisessa korjaustiedostossa, joka ei liity pg_stat_statements. EXPLAIN PUSKURIT-vaihtoehdolla ilmoittaa suunnitteluvaiheessa käytettyjen puskurien määrän:
Seq Scan on pg_class (actual rows=386 loops=1) Buffers: shared hit=9 read=4 Planning Time: 0.782 ms Buffers: shared hit=103 read=11 Execution Time: 0.219 ms
Inkrementaalinen lajittelu
Tapauksissa, joissa tarvitaan lajittelua useiden avainten mukaan (k1, k2, k3…), suunnittelija voi nyt hyödyntää tietämystä, että tiedot on lajiteltu jo useiden ensimmäisten avainten mukaan (esim. k1 ja k2). Tässä tapauksessa et voi lajitella kaikkia tietoja uudelleen, vaan jakaa ne peräkkäisiin ryhmiin, joilla on samat arvot k1 ja k2, ja "lajitella" ne uudelleen avaimella k3.
Näin ollen koko lajittelu jakautuu useisiin peräkkäisiin pienempikokoisiin lajitteluihin. Tämä vähentää tarvittavan muistin määrää ja mahdollistaa myös ensimmäisten tietojen palauttamisen ennen kuin lajittelu on valmis.
Incremental Sort (actual rows=2949857 loops=1) Sort Key: ticket_no, passenger_id Presorted Key: ticket_no Full-sort Groups: 92184 Sort Method: quicksort Memory: avg=31kB peak=31kB -> Index Scan using tickets_pkey on tickets (actual rows=2949857 loops=1) Planning Time: 2.137 ms Execution Time: 2230.019 ms
UI/UX parannuksia
Kuvakaappauksia on kaikkialla!
Nyt jokaisella välilehdellä on mahdollisuus nopeasti ota kuvakaappaus välilehdestä leikepöydälle koko välilehden leveydeltä ja syvyydestä - "näkymä" oikealla ylhäällä:
Itse asiassa suurin osa tämän julkaisun kuvista on saatu tällä tavalla.
Suosituksia solmuista
Niitä ei ole vain enemmän, vaan jokaisesta voit seuraamalla linkkiä:
Poistetaan arkistosta
Jotkut ovat pyytäneet kykyä poista "ehdottomasti" myös suunnitelmat, joita ei ole julkaistu arkistossa - klikkaa vain vastaavaa kuvaketta:
No, älkäämme unohtako, että meillä on johon voit kirjoittaa kommentteja ja ehdotuksia.
Lähde: will.com