ಅರ್ಧ ವರ್ಷದ ಹಿಂದೆ
ಕಳೆದ ತಿಂಗಳುಗಳಲ್ಲಿ ನಾವು ಅವನ ಬಗ್ಗೆ ಮಾಡಿದ್ದೇವೆ
ಮತ್ತು ಈಗ ನೀವು ಬಳಸಬಹುದಾದ ಹೊಸ ವೈಶಿಷ್ಟ್ಯಗಳ ಬಗ್ಗೆ ಹೇಳಲು ನಾವು ಸಿದ್ಧರಿದ್ದೇವೆ.
ವಿವಿಧ ಯೋಜನೆ ಸ್ವರೂಪಗಳಿಗೆ ಬೆಂಬಲ
ವಿನಂತಿಯೊಂದಿಗೆ ಲಾಗ್ನಿಂದ ಯೋಜನೆ ಮಾಡಿ
ಕನ್ಸೋಲ್ನಿಂದ ನೇರವಾಗಿ, ನಾವು ಸಾಲಿನಿಂದ ಪ್ರಾರಂಭಿಸಿ ಸಂಪೂರ್ಣ ಬ್ಲಾಕ್ ಅನ್ನು ಆಯ್ಕೆ ಮಾಡುತ್ತೇವೆ ಪ್ರಶ್ನೆ ಪಠ್ಯ, ಎಲ್ಲಾ ಪ್ರಮುಖ ಸ್ಥಳಗಳೊಂದಿಗೆ:
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_statementಗಳಿಗೆ ಸಂಬಂಧಿಸದ ಮತ್ತೊಂದು ಪ್ಯಾಚ್ನಲ್ಲಿ ಪ್ರತಿಫಲಿಸುತ್ತದೆ. 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