Tác động của CLUSTER đến hiệu suất

Tôi đang cố gắng tối ưu hóa cơ sở dữ liệu Postgres 9.2 của mình để tăng tốc truy vấn với các hạn chế ngày.

Tôi có một timestampcột, nhưng chủ yếu là tôi yêu cầu một ngày nào đó, vì vậy tôi đã tạo một chỉ mục timestampđể datephân tích cú pháp:

CREATE INDEX foo_my_timestamp_idx
ON foo
USING btree
((my_timestamp::date) DESC);

Bây giờ, để tăng CLUSTER foobảng hiệu suất tôi sử dụng chỉ mục ở trên:

CLUSTER foo USING foo_my_timestamp_idx;

Theo hướng dẫn trên SQL-CLUSTER , bảng

được sắp xếp lại vật lý dựa trên thông tin chỉ số

Tôi tự hỏi liệu có ảnh hưởng đến hiệu suất cho các truy vấn khác bằng cách sử dụng PK của bảng không (giả sử id_foo). Có bất kỳ nhược điểm?

Vâng, có thể có nhược điểm. Nếu một truy vấn khác xem xét một phân đoạn dữ liệu khác không được xác định theo ngày, thì có thể mất một lần thực hiện nếu các hàng được trải ra trên nhiều trang dữ liệu hơn. Cũng giống như cách lợi nhuận truy vấn đầu tiên của bạn. Điều đó hoàn toàn phụ thuộc vào thông tin không có trong câu hỏi của bạn.

các truy vấn khác bằng cách sử dụng PK của bảng (giả sử id_foo)

Đó có thể là bất cứ điều gì . Nó phụ thuộc vào những gì bạn có và những gì bạn truy vấn chính xác . Truy vấn một hàng không bị ảnh hưởng theo một trong hai cách, nhưng nhiều hàng có thể.

Xin lưu ý rằng CLUSTERviết lại bảng trong điều kiện nguyên sơ như VACUUM FULL(loại bỏ các bộ dữ liệu đã chết, thu nhỏ kích thước vật lý của bảng, viết lại các chỉ mục) Vì vậy, bạn có thể thấy hiệu ứng tích cực ngay lập tức đối với hiệu suất đọc độc lập với thứ tự sắp xếp. (Giống như bạn sẽ nhận được VACUUM FULL.)
Sau đó CLUSTER, bạn có thể muốn chạy một VACUUMbảng đơn giản trên bảng để cập nhật bản đồ hiển thị - điều này có thể cho phép quét chỉ mục.

Tất cả lợi ích của CLUSTERthu nhỏ với tần số ghi.

Ngoài ra, nếu bạn có nhiều cập nhật cho bảng, CLUSTERthực sự có thể ảnh hưởng đến hiệu suất ghi bằng cách xóa "phòng ngọ nguậy" cho các cập nhật NÓNG trên cùng một trang dữ liệu. Bạn có thể chống lại hiệu ứng đó với FILLFACTORcài đặt dưới 100. Một lần nữa, tùy thuộc vào địa phương của các hàng được cập nhật, v.v.

Liên quan:

• Tối ưu hóa chỉ mục với ngày

Dù bằng cách nào, tôi có thể sẽ không lập chỉ mục và cụm my_timestamp::date, nhưng my_timestamptrực tiếp. Không có gì mất, một cái gì đó đã đạt được. Dàn diễn viên rất rẻ, nhưng vẫn không rẻ hơn chút nào. Và chỉ mục có thể hỗ trợ nhiều truy vấn hơn.

CREATE INDEX foo_my_timestamp_idx ON foo (my_timestamp);

Mặc dù một datechỉ chiếm 4 byte trên đĩa và timestampchiếm 8 byte, phần chênh lệch được thường thua đệm liên kết cho trường hợp của bạn, và cả hai chỉ số có chính xác cùng kích thước.

Thứ tự của nhiều hàng trong cùng một ngày do chỉ số biểu thức của bạn là tùy ý. Vẫn có thể có hai dấu thời gian giống hệt nhau, nhưng với 6 chữ số phân số thường rất khó xảy ra. Ngoài ra, bạn nhận được một thứ tự xác định của các hàng, có thể có những lợi thế khác nhau.

Tôi cũng bỏ DESCtừ khóa vì Postgres có thể đọc các chỉ mục ngược gần như nhanh về phía trước. (Tuy nhiên, sắp xếp thứ tự các vấn đề cho các chỉ mục nhiều màu!) Khác:

• Tối ưu hóa truy vấn trên một loạt dấu thời gian (hai cột)

Thay vì:

SELECT * FROM foo
WHERE my_timestamp::date = '2016-07-25';

Bây giờ bạn sẽ sử dụng:

SELECT * FROM foo
WHERE  my_timestamp >= '2016-07-25'  -- this is a timestamp literal now
WHERE  my_timestamp <  '2016-07-26';

Hiệu suất tương tự.

Nếu bạn không cần các thành phần thời gian của cột ở tất cả , chuyển đổi các cột để date...

Làm thế nào để cuộn lại CLUSTER?

CLUSTERtrên một bảng có thể được khôi phục ROLLBACKgiống như bất kỳ lệnh thông thường nào khác miễn là giao dịch chưa được thực hiện.

Tuy nhiên, tôi trích dẫn hướng dẫn :

CLUSTERkhông có bất kỳ tham số nào bao gồm tất cả các bảng được phân cụm trước đó trong cơ sở dữ liệu hiện tại mà người dùng gọi sở hữu hoặc tất cả các bảng như vậy nếu được gọi bởi một siêu người dùng. Hình thức này CLUSTERkhông thể được thực thi trong một khối giao dịch.

Bạn luôn có thể chạy CLUSTERvới một chỉ mục khác để thay đổi thứ tự vật lý của các hàng một lần nữa.