2016-01-28 14 views
5

Tôi đang cố hiểu những khác biệt về tốc độ đáng kể mà tôi thấy giữa các truy vấn DB tương tự và tôi đã hy vọng một số hiểu biết về lý do tập hợp nhất định chậm hơn nhiều so với các kết hợp khác.Hiểu về hiệu suất json_agg trong Postgres 9.5

tôi nhận thấy một số vấn đề tốc độ với một truy vấn thu hồi tài liệu đơn giản, và một phần đáng kể của nó dường như là json_agg chức năng:

SELECT containers.*, json_agg(content_items.*) as items FROM containers 
INNER JOIN content_items ON containers.id = content_items.container_id 
GROUP BY containers.id 
ORDER BY containers.order_date DESC, containers.id DESC 
LIMIT 25 OFFSET 0; 

Hiển thị thời gian truy vấn tổng cộng khoảng 500ms, với hơn 400ms đó chi tiêu trong bước tập hợp:

GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=78.818..484.071 rows=17455 loops=1) 

Đơn giản chỉ cần chuyển đổi json_agg để array_agg mang lại tổng thời gian xuống khoảng 150ms, mặc dù khoảng một nửa thời gian vẫn dành gộp:

GroupAggregate (cost=11921.58..12607.34 rows=17540 width=1553) (actual time=81.975..147.207 rows=17455 loops=1) 

Thực hiện các truy vấn mà không nhóm hoặc tập hợp mang lại tổng thời gian xuống đến 25ms, mặc dù điều đó sẽ trở lại một số biến của containers tùy thuộc vào bao nhiêu content_items là ở mỗi người.

Có lý do nào cho số json_agg để áp đặt hình phạt như vậy không? Có cách nào thực hiện để truy xuất số lượng hàng được đặt là container hàng, cùng với tất cả các số content_items và chỉ tổng hợp trong lớp ứng dụng không?

Trả lời

0

Bạn có thể thực hiện hai truy vấn: Đầu tiên sẽ nhận được các vùng chứa thích hợp, đặt hàng và giới hạn ở 25. Thứ hai sẽ lấy content_items sử dụng mệnh đề where-in. Sau đó, ứng dụng có thể lọc và ánh xạ nội dung vào các vùng chứa thích hợp.

Các vấn đề liên quan