Việc tăng work_mem dường như làm cho việc sắp xếp nhanh hơn khoảng 8 lần:(172639.670 - 169311.063) / (167975.549 - 167570.669)
. Nhưng vì việc sắp xếp chỉ chiếm một phần nhỏ thời gian thực hiện tổng thể, nên việc nhanh hơn gấp 1000 lần cũng không thể làm cho mọi thứ trở nên tốt hơn nhiều. Đây là quá trình quét seq đang chiếm nhiều thời gian.
Phần lớn thời gian quét seq có lẽ dành cho IO. Bạn có thể xem bằng cách chạy EXPLAIN (ANALYZE, BUFFERS)
sau khi bật track_io_timing.
Ngoài ra, việc quét seq song song thường không hữu ích lắm, vì hệ thống IO thường có thể cung cấp toàn bộ dung lượng của nó cho một đầu đọc duy nhất, do sự kỳ diệu của đầu đọc. Và đôi khi những người đọc song song thậm chí có thể giẫm chân lên nhau, khiến toàn bộ màn trình diễn trở nên tồi tệ hơn. Bạn có thể tắt tính năng song song với set max_parallel_workers_per_gather TO 0;
Điều này có thể làm cho mọi thứ nhanh hơn và nếu không, nó sẽ ít nhất làm cho kế hoạch GIẢI THÍCH dễ hiểu hơn.
Bạn đang tìm nạp hơn 3% bảng:193963 / (193963 + 6041677)
. Các chỉ mục có thể không hữu ích lắm khi bạn đang tìm nạp quá nhiều. Nếu đúng như vậy, bạn sẽ muốn có một chỉ mục kết hợp chứ không phải các chỉ mục riêng lẻ. Vì vậy, bạn muốn có một chỉ mục trên (client, event_name, date(datetime))
. Sau đó, bạn cũng cần thay đổi truy vấn để sử dụng date(datetime)
thay vì to_char(datetime, 'YYYY-MM-DD')
. Bạn cần thực hiện thay đổi này vì to_char không phải là bất biến và do đó không thể được lập chỉ mục.