🥇 د 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:

د وخت شوي I/O عملیات فعالوي. دا ترتیب د ډیفالټ لخوا غیر فعال شوی ، ځکه چې دا عملیاتي سیسټم ته اړتیا لري چې په دوامداره توګه اوسني وخت پوښتنې وکړي ، کوم چې کولی شي په ځینو پلیټ فارمونو کې شیان د پام وړ ورو کړي. تاسو کولی شئ د pg_test_timing افادیت وکاروئ ترڅو ستاسو په پلیټ فارم کې د وخت سر سر اټکل وکړئ. د I/O احصایې د pg_stat_database لید له لارې ترلاسه کیدی شي، په توضیحي محصول کې (کله چې د BUFFERS پیرامیټر کارول کیږي) او د pg_stat_statements لید له لارې.

دا اختیار په محلي ناسته کې هم فعال کیدی شي:

SET track_io_timing = TRUE;

ښه، اوس غوره برخه دا ده چې موږ د دې معلوماتو پوهیدل او ښودل زده کړل، د اعدام ونې ټول بدلونونه په پام کې نیولو سره:

دلته تاسو لیدلی شئ چې د ټول اجرا کولو وخت 0.790ms څخه، 0.718ms د یوې پاڼې ډاټا لوستل، 0.044ms - لیکل کول، او یوازې 0.028ms په نورو ټولو ګټورو فعالیتونو مصرف شوي!

راتلونکی د 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 ښه والی

سکرین شاټونه هرچیرې دي!

اوس په هر ټب کې د ګړندي کولو فرصت شتون لري کلپ بورډ ته د ټب سکرین شاټ واخلئ د ټب ټول پراخوالی او ژوروالی لپاره - "لظاهر" ښیې پورته:

په حقیقت کې، د دې خپرونې ډیری عکسونه پدې ډول اخیستل شوي.

په نوډونو کې سپارښتنې

دلته نه یوازې د دوی څخه ډیر دي، مګر د هر یو په اړه چې تاسو یې کولی شئ مقاله په تفصیل سره ولولئد لینک په تعقیب کولو سره:

له آرشیف څخه لرې کول

ځینو د وړتیا غوښتنه کړې "بلکل" حذف کړئ حتی هغه پلانونه چې په آرشیف کې ندي خپاره شوي - مهرباني وکړئ یوازې په اړونده نښه کلیک وکړئ:

ښه، راځئ چې دا هیر نکړو چې موږ لرو د ملاتړ ګروپچیرې چې تاسو کولی شئ خپل نظرونه او وړاندیزونه ولیکئ.

سرچینه: www.habr.com

د PostgreSQL پوښتنو پلانونو پوهیدل حتی په اسانۍ سره