Հասկանալով PostgreSQL հարցումների պլաններն էլ ավելի հարմար

Վեց ամիս առաջ ներկայացրել ենք բացատրել.tensor.ru - հանրային Ծառայություն հարցումների պլանների վերլուծության և պատկերացման համար դեպի PostgreSQL:

Անցած ամիսների ընթացքում մենք արել ենք նրա մասին զեկույց PGConf.Russia 2020-ում, պատրաստել է ամփոփագիր SQL հարցումների արագացման մասին հոդված հիմնվելով այն առաջարկությունների վրա, որոնք նա տալիս է ... բայց ամենակարևորը, մենք հավաքեցինք ձեր կարծիքը և նայեցինք իրական օգտագործման դեպքերին:

Եվ հիմա մենք պատրաստ ենք ձեզ պատմել այն նոր հնարավորությունների մասին, որոնք դուք կարող եք օգտագործել:

Աջակցություն տարբեր պլանի ձևաչափերին

Պլանավորեք մատյանից՝ խնդրանքի հետ մեկտեղ

Անմիջապես վահանակից մենք ընտրում ենք ամբողջ բլոկը, սկսած տողից Հարցման տեքստ, բոլոր առաջատար տարածքներով.

        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)

... և նետեք այն ամենը, ինչ պատճենված է անմիջապես պլանի համար դաշտ, առանց որևէ բան առանձնացնելու.

Ելքի ժամանակ մենք նաև բոնուս ենք ստանում ապամոնտաժված պլանի համար համատեքստի ներդիր, որտեղ մեր խնդրանքը ներկայացված է իր ողջ փառքով.

JSON և 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
  }
]"

Նույնիսկ արտաքին մեջբերումներով, ինչպես pgAdmin-ը պատճենում է, նույնիսկ առանց - մենք նետում ենք նույն դաշտը, արդյունքը գեղեցկությունն է.

Ընդլայնված պատկերացում

Պլանավորման ժամանակը / Կատարման ժամանակը

Այժմ դուք կարող եք ավելի լավ տեսնել, թե որտեղ է ծախսվել լրացուցիչ ժամանակը հարցումը կատարելիս.

I/O Ժամկետ

Երբեմն պետք է գործ ունենալ մի իրավիճակի հետ, երբ ռեսուրսների առումով թվում է, թե շատ բան չի կարդացվել և գրվել, բայց թվում է, թե կատարման ժամանակը ինչ-ինչ պատճառներով անհամապատասխան մեծ է:

Այստեղ պետք է ասել.Ահ, երևի այդ պահին սերվերի սկավառակը չափազանց ծանրաբեռնված էր, դրա համար էլ այդքան երկար տևեց կարդալը։«Բայց ինչ-որ կերպ դա այնքան էլ ճշգրիտ չէ ...

Բայց դա կարելի է միանգամայն հուսալիորեն որոշել։ Փաստն այն է, որ PG սերվերի կազմաձևման տարբերակներից կան track_io_timing:

Միացնում է ժամանակի մուտքի/ելքի գործողությունները: Այս պարամետրը լռելյայն անջատված է, քանի որ այն պահանջում է, որ օպերացիոն համակարգն անընդհատ հարցումներ կատարի ընթացիկ ժամանակը, ինչը կարող է զգալիորեն դանդաղեցնել որոշ հարթակներում: Դուք կարող եք օգտագործել pg_test_timing ծրագիրը՝ ձեր հարթակում ժամանակի ծախսերը գնահատելու համար: I/O վիճակագրությունը կարելի է ստանալ pg_stat_database տեսքի միջոցով, EXPLAIN ելքում (երբ օգտագործվում է BUFFERS պարամետրը) և pg_stat_statements տեսքի միջոցով:

Այս տարբերակը կարող է ակտիվացվել նաև տեղական նստաշրջանի ընթացքում.

SET track_io_timing = TRUE;

Դե, հիմա ամենալավն այն է, որ մենք սովորել ենք հասկանալ և ցուցադրել այս տվյալները՝ հաշվի առնելով կատարման ծառի բոլոր փոխակերպումները.

Այստեղ դուք կարող եք տեսնել, որ կատարման ընդհանուր ժամանակի 0.790 մվ-ից 0.718 մվ-ը պահանջել է մեկ էջի տվյալներ կարդալու համար, 0.044 մվ-ը՝ դրանք գրելով, և միայն 0.028 մվ-ն է ծախսվել մնացած բոլոր օգտակար գործողությունների վրա:

Ապագան PostgreSQL 13-ով

Նորությունների ամբողջական ակնարկի համար տե՛ս մանրամասն հոդվածում, իսկ խոսքը կոնկրետ պլանների փոփոխությունների մասին է։

Պլանավորման բուֆերներ

Ժամանակացույցին հատկացված ռեսուրսների հաշվառումն արտացոլվում է pg_stat_statements-ի հետ չկապված մեկ այլ կարկատում: ԲԱՑԱՏՐԵԼ BUFFERS տարբերակով կհաղորդի պլանավորման փուլում օգտագործված բուֆերների քանակը.

 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

Աճող տեսակավորում

Այն դեպքերում, երբ անհրաժեշտ է տեսակավորում ըստ բազմաթիվ ստեղների (k1, k2, k3…), պլանավորողն այժմ կարող է օգտվել այն բանից, որ տվյալներն արդեն տեսակավորված են առաջին ստեղներից մի քանիսի միջոցով (օրինակ՝ k1 և k2): Այս դեպքում դուք չեք կարող վերադասավորել բոլոր տվյալները նորովի, այլ դրանք բաժանել հաջորդական խմբերի՝ k1 և k2 նույն արժեքներով և «վերադասավորել» դրանք k3 ստեղնով:

Այսպիսով, ամբողջ տեսակավորումը բաժանվում է ավելի փոքր չափի մի քանի հաջորդական տեսակավորման: Սա նվազեցնում է պահանջվող հիշողության ծավալը, ինչպես նաև թույլ է տալիս վերադարձնել առաջին տվյալները նախքան ամբողջ տեսակավորման ավարտը:

 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 բարելավումներ

Սքրինշոթներն ամենուր են:

Այժմ յուրաքանչյուր ներդիրում կա արագ հնարավորություն վերցնել ներդիրի սքրինշոթը սեղմատախտակին ներդիրի ամբողջ լայնության և խորության համար - «տեսողություն» աջ վերևում:

Փաստորեն, այս հրապարակման նկարների մեծ մասը ստացվել է այս կերպ.

Առաջարկություններ հանգույցների վերաբերյալ

Դրանք ոչ միայն ավելի շատ են, այլև յուրաքանչյուրի մասին, որը դուք կարող եք մանրամասն կարդացեք հոդվածըհետևելով հղմանը.

Հեռացվում է արխիվից

Ոմանք խնդրել են կարողություն ջնջել «բացարձակապես» նույնիսկ պլաններ, որոնք չեն հրապարակվել արխիվում, խնդրում ենք պարզապես սեղմել համապատասխան պատկերակը.

Դե, չմոռանանք, որ ունենք Աջակցող խումբորտեղ կարող եք գրել ձեր մեկնաբանությունները և առաջարկությունները:

Source: www.habr.com