PostgreSQL ਪੁੱਛਗਿੱਛ ਯੋਜਨਾਵਾਂ ਨੂੰ ਹੋਰ ਵੀ ਸੁਵਿਧਾਜਨਕ ਢੰਗ ਨਾਲ ਸਮਝਣਾ

ਡੇਢ ਸਾਲ ਪਹਿਲਾਂ ਅਸੀਂ ਪੇਸ਼ ਕੀਤਾ explain.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 ਟਾਈਮਿੰਗ

ਕਈ ਵਾਰ ਤੁਹਾਨੂੰ ਅਜਿਹੀ ਸਥਿਤੀ ਨਾਲ ਨਜਿੱਠਣਾ ਪੈਂਦਾ ਹੈ ਜਿੱਥੇ, ਸਰੋਤਾਂ ਦੇ ਰੂਪ ਵਿੱਚ, ਅਜਿਹਾ ਲਗਦਾ ਹੈ ਕਿ ਬਹੁਤ ਜ਼ਿਆਦਾ ਪੜ੍ਹਿਆ ਅਤੇ ਲਿਖਿਆ ਨਹੀਂ ਗਿਆ ਸੀ, ਪਰ ਲਾਗੂ ਕਰਨ ਦਾ ਸਮਾਂ ਅਸੰਗਤ ਰੂਪ ਵਿੱਚ ਲੰਬਾ ਜਾਪਦਾ ਹੈ.

ਇੱਥੇ ਸਾਨੂੰ ਕਹਿਣਾ ਹੈ: "ਓਹ, ਸ਼ਾਇਦ ਉਸ ਸਮੇਂ ਸਰਵਰ 'ਤੇ ਡਿਸਕ ਬਹੁਤ ਜ਼ਿਆਦਾ ਲੋਡ ਹੋ ਗਈ ਸੀ, ਇਸ ਲਈ ਇਸਨੂੰ ਪੜ੍ਹਨ ਵਿੱਚ ਇੰਨਾ ਸਮਾਂ ਲੱਗਿਆ!"ਪਰ ਕਿਸੇ ਤਰ੍ਹਾਂ ਇਹ ਬਹੁਤ ਸਹੀ ਨਹੀਂ ਹੈ ...

ਪਰ ਇਹ ਬਿਲਕੁਲ ਭਰੋਸੇਯੋਗ ਢੰਗ ਨਾਲ ਨਿਰਧਾਰਤ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ. ਤੱਥ ਇਹ ਹੈ ਕਿ ਪੀਜੀ ਸਰਵਰ ਸੰਰਚਨਾ ਵਿਕਲਪਾਂ ਵਿੱਚੋਂ ਇੱਕ ਹੈ track_io_timing:

I/O ਕਾਰਵਾਈਆਂ ਦੇ ਸਮੇਂ ਨੂੰ ਸਮਰੱਥ ਬਣਾਉਂਦਾ ਹੈ। ਇਹ ਵਿਕਲਪ ਪੂਰਵ-ਨਿਰਧਾਰਤ ਤੌਰ 'ਤੇ ਅਸਮਰੱਥ ਹੈ ਕਿਉਂਕਿ ਇਸਨੂੰ ਮੌਜੂਦਾ ਸਮੇਂ ਲਈ ਲਗਾਤਾਰ ਓਪਰੇਟਿੰਗ ਸਿਸਟਮ ਦੀ ਪੁੱਛਗਿੱਛ ਕਰਨ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ, ਜੋ ਕੁਝ ਪਲੇਟਫਾਰਮਾਂ 'ਤੇ ਕਾਰਗੁਜ਼ਾਰੀ ਨੂੰ ਮਹੱਤਵਪੂਰਨ ਤੌਰ 'ਤੇ ਹੌਲੀ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੇ ਪਲੇਟਫਾਰਮ 'ਤੇ ਸਮੇਂ ਦੀ ਲਾਗਤ ਦਾ ਅੰਦਾਜ਼ਾ ਲਗਾਉਣ ਲਈ, ਤੁਸੀਂ pg_test_timing ਉਪਯੋਗਤਾ ਦੀ ਵਰਤੋਂ ਕਰ ਸਕਦੇ ਹੋ। I/O ਅੰਕੜੇ pg_stat_database ਵਿਊ ਰਾਹੀਂ ਪ੍ਰਾਪਤ ਕੀਤੇ ਜਾ ਸਕਦੇ ਹਨ, EXPLAIN ਆਉਟਪੁੱਟ ਵਿੱਚ (ਜਦੋਂ 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