nửa năm trước - công cộng đến PostgreSQL.
Trong những tháng qua chúng tôi đã làm về anh ấy , chuẩn bị một bản tóm tắt dựa trên các đề xuất mà nó đưa ra... nhưng quan trọng nhất, chúng tôi đã thu thập phản hồi của bạn và xem xét các trường hợp sử dụng thực tế.
Và bây giờ chúng tôi sẵn sàng cho bạn biết về các tính năng mới mà bạn có thể sử dụng.
Hỗ trợ cho các định dạng kế hoạch khác nhau
Lập kế hoạch từ nhật ký, cùng với yêu cầu
Trực tiếp từ bảng điều khiển, chúng tôi chọn toàn bộ khối, bắt đầu từ dòng có Văn bản truy vấn, với tất cả các khoảng trắng hàng đầu:
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)
... và ném mọi thứ được sao chép trực tiếp vào trường cho kế hoạch mà không tách rời bất cứ thứ gì:
Ở đầu ra, chúng tôi cũng nhận được tiền thưởng cho kế hoạch tháo rời tab ngữ cảnh, nơi yêu cầu của chúng tôi được trình bày trong tất cả vinh quang của nó:
JSON và 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
}
]"Ngay cả với các trích dẫn bên ngoài, như các bản sao pgAdmin, ngay cả khi không có - chúng tôi ném vào cùng một trường, đầu ra vẫn đẹp:
Trực quan hóa nâng cao
Thời gian lập kế hoạch / Thời gian thực hiện
Bây giờ bạn có thể thấy rõ hơn thời gian thừa đã đi đâu khi thực hiện truy vấn:
Thời gian I / O
Đôi khi bạn phải đối mặt với một tình huống mà về mặt tài nguyên, có vẻ như không có quá nhiều thứ được đọc và viết, nhưng có vẻ như thời gian thực hiện lại lớn một cách khó hiểu vì một lý do nào đó.
Nó phải được nói ở đây:Ôi, lúc đó ổ đĩa trên server chắc bận quá nên đọc lâu quá!"Nhưng bằng cách nào đó nó không chính xác lắm ...
Nhưng nó có thể được xác định hoàn toàn đáng tin cậy. Thực tế là trong số các tùy chọn cấu hình của máy chủ PG có :
Cho phép các hoạt động I/O được hẹn giờ. Cài đặt này bị tắt theo mặc định vì nó yêu cầu hệ điều hành liên tục truy vấn thời gian hiện tại, điều này có thể làm mọi thứ chậm lại đáng kể trên một số nền tảng. Bạn có thể sử dụng tiện ích pg_test_timing để ước tính chi phí tính thời gian trên nền tảng của mình. Số liệu thống kê I/O có thể thu được thông qua chế độ xem pg_stat_database, trong đầu ra EXPLAIN (khi tham số BUFFERS được sử dụng) và thông qua chế độ xem pg_stat_statements.
Tùy chọn này cũng có thể được bật trong phiên cục bộ:
SET track_io_timing = TRUE;Chà, bây giờ phần tốt nhất là chúng ta đã học cách hiểu và hiển thị dữ liệu này, có tính đến tất cả các phép biến đổi của cây thực thi:
Tại đây, bạn có thể thấy rằng trong tổng thời gian thực hiện là 0.790 mili giây, 0.718 mili giây đã đọc một trang dữ liệu, 0.044 mili giây - viết nó và chỉ 0.028 mili giây được sử dụng cho tất cả các hoạt động hữu ích khác!
Tương lai với PostgreSQL 13
Để biết tổng quan đầy đủ về tính năng mới, hãy xem và chúng tôi đang nói cụ thể về những thay đổi trong kế hoạch.
Lập kế hoạch đệm
Kế toán tài nguyên được phân bổ cho bộ lập lịch trình được phản ánh trong một bản vá khác không liên quan đến pg_stat_statements. GIẢI THÍCH với tùy chọn BUFFERS sẽ báo cáo số lượng bộ đệm được sử dụng trong giai đoạn lập kế hoạch:
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
sắp xếp tăng dần
Trong trường hợp cần sắp xếp theo nhiều khóa (k1, k2, k3…), người lập kế hoạch giờ đây có thể tận dụng lợi thế khi biết rằng dữ liệu đã được sắp xếp theo một số khóa đầu tiên (ví dụ: k1 và k2). Trong trường hợp này, bạn không thể sắp xếp lại tất cả dữ liệu mà hãy chia chúng thành các nhóm liên tiếp có cùng giá trị k1 và k2 và “sắp xếp lại” theo khóa k3.
Do đó, toàn bộ cách sắp xếp được chia thành nhiều cách sắp xếp liên tiếp có kích thước nhỏ hơn. Điều này làm giảm dung lượng bộ nhớ cần thiết và cũng cho phép bạn trả lại dữ liệu đầu tiên trước khi toàn bộ quá trình sắp xếp hoàn tất.
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
Cải tiến UI/UX
Ảnh chụp màn hình ở khắp mọi nơi!
Bây giờ trên mỗi tab có một cơ hội để nhanh chóng chụp ảnh màn hình của tab vào clipboard cho toàn bộ chiều rộng và chiều sâu của tab - "tầm nhìn" trên cùng bên phải:
Trên thực tế, hầu hết các hình ảnh cho ấn phẩm này được lấy theo cách này.
Khuyến nghị về các nút
Không chỉ có nhiều người trong số họ, mà về mỗi người bạn có thể bằng cách theo liên kết:
Xóa khỏi kho lưu trữ
Một số đã yêu cầu khả năng xóa "hoàn toàn" ngay cả các kế hoạch không được xuất bản trong kho lưu trữ - vui lòng chỉ cần nhấp vào biểu tượng tương ứng:
Chà, đừng quên rằng chúng ta có nơi bạn có thể viết nhận xét và đề xuất của mình.
Nguồn: www.habr.com