Như bạn đã ám chỉ, cách duy nhất để thực sự biết là để so sánh các kế hoạch thực hiện. Trên thực tế, cách tốt nhất là sử dụng EXPLAIN ANALYZE , để nó thực sự thực thi truy vấn và chèn kết quả vào đầu ra với các ước tính, vì vậy bạn có thể hiểu công cụ lập kế hoạch truy vấn so với thực tế.
Tuy nhiên, nói chung, những gì tôi sẽ làm trong tình huống như thế này có thể là tạo bảng tạm thời cho tập hợp con ứng dụng khách và sau đó là JOIN cho orders bàn. Bạn có thể tùy ý sử dụng WITH thay vào đó để thực hiện mọi thứ trong một truy vấn.
Vì vậy, một cái gì đó như:
CREATE TEMP TABLE tmp_clients AS
SELECT c.clientid
FROM clients c
WHERE c.city = 'New York'
ORDER BY c.clientid;
SELECT *
FROM orders AS o
JOIN tmp_clients AS c ON (o.clientid = c.clientid)
ORDER BY o.clientid;
Bằng cách này, tmp_clients chỉ chứa các khách hàng ở New York - ~ 5K hàng - và chính bảng đó sẽ được kết hợp với bảng đơn đặt hàng.
Bạn cũng có thể, để tối ưu hóa hơn nữa, hãy tạo một chỉ mục trên bảng tạm thời (trên clientid) và sau đó ANALYZE nó trước khi thực hiện JOIN để đảm bảo rằng JOIN được thực hiện hoàn toàn trên chỉ mục. Bạn muốn kiểm tra các kế hoạch truy vấn trong từng trường hợp để xem sự khác biệt tương đối (hoặc chỉ cần ghi nhớ điều này nếu JOIN không nhanh như bạn muốn).
Phản hồi nhận xét từ @poshest:
Nghe giống như bảng tạm thời đang xếp chồng lên nhau, điều này sẽ làm tăng dung lượng bộ nhớ và, đối với một kết nối hoạt động lâu dài, chức năng dường như bị rò rỉ bộ nhớ.
Trong trường hợp đó, nó sẽ không phải là một rò rỉ thực sự, như bảng tạm thời được xác định phạm vi kết nối. Chúng tự động biến mất, nhưng không phải cho đến khi kết nối kết thúc. Tuy nhiên, bạn có thể làm cho chúng biến mất ngay lập tức khi làm xong. Đơn giản chỉ cần DROP bảng như bạn làm với bất kỳ bảng nào khác sau khi bạn hoàn thành chúng và tôi nghi ngờ rằng bạn sẽ có thể gọi hàm nhiều lần - trên cùng một kết nối - mà không cần tăng dấu chân bộ nhớ đơn điệu giống nhau.
