Using Historical Data to Confirm Performance Improvements

All Your GUCs in a Row: log_destination and logging_collector

Bài viết giải thích vai trò của hai tham số GUC log_destination và logging_collector trong PostgreSQL, mô tả cách logging collector hoạt động như một daemon dựa trên pipe để tránh mất và garbled log messages. Khi bật logging_collector, PostgreSQL phải khởi động lại vì daemon được tạo trong quá trình khởi động, và các định dạng log như stderr, csvlog và jsonlog đều được đưa vào pipe này. Tuy nhiên, dưới tải cao, collector có thể trở thành điểm nghẽn và làm giãn cả instance, trong khi việc sử dụng syslog lại có nguy cơ silently drop messages khi hệ thống quá tải. Bài cũng so sánh mặc định của log_destination trên các nền tảng phổ biến: Debian/Ubuntu thường để stderr, PGDG RPMs thường dùng csvlog, Docker images và một số dịch vụ quản lý có thể pre‑configure jsonlog hoặc syslog tùy theo nhà cung cấp. Từ đó, tác giả khuyên trong môi trường production nên chọn định dạng log phù hợp với hệ thống giám sát, bật logging_collector chỉ khi cần lưu trữ tập trung và luôn monitor throughput để tránh stall, đồng thời cân nhắc sử dụng syslog với buffer đủ lớn hoặc các giải pháp bên ngoài như Fluentd để tránh mất log.

Bài giải thích chi tiết về log_destination và logging_collector GUCs giúp bạn hiểu rõ cơ chế logging của PostgreSQL, từ đó tối ưu hóa cấu hình giám sát và xử lý log hiệu quả trong môi trường production.

Connection Pool Sizing, Measured: Why 48 Connections Beat 400

Bài viết thực nghiệm trên PostgreSQL bằng cách tăng số kết nối từ 1 lên 400 để đo …

LibreDB Studio: an open source, self-hosted SQL IDE for PostgreSQL in the browser

LibreDB Studio là IDE SQL mã nguồn mở, tự host cho PostgreSQL chạy trên trình duyệt, triển …

SQL Indexing Explained: Composite Indexes and Column Order

Bài viết bắt đầu bằng việc tạo bảng comments với 1 triệu bản ghi trong PostgreSQL để đánh …

Postgres 19: How Our Advice Has Changed Since...

Bài viết đánh giá lại những lời khuyên trước đây về các tính năng như COPY, TOAST, BRIN, covering indexes và partitioning trong PostgreSQL, xem xét những thay đổi từ các phiên bản Postgres gần đây và đưa ra khuyến nghị cho phiên bản sắp tới (Postgres 19).

Một lập trình viên nên đọc bài này để cập nhật cách tối ưu hóa cơ sở dữ liệu PostgreSQL 19 mới nhất, đặc biệt là về các kỹ thuật như COPY, TOAST, BRIN, và cách sử dụng các chỉ mục bù và phân vùng hiệu quả, giúp cải thiện hiệu suất và quản lý tài nguyên trong ứng dụng hiện đại.

What AI Thinks a DBA Does All Day

Bài viết bắt đầu bằng việc so sánh hình dung của AI về một ngày làm việc của DBA (backup, tài liệu, kiểm tra sức khỏe chủ động và một cửa sổ làm việc im ắng) với ngày thực tế của tác giả. Theo AI, ngày DBA chỉ gồm sáu hoạt động chính, trong khi bản ghi thực tế của tác giả liệt kê lên tới mười ba việc khác nhau. Sự chênh lệch này phản ánh việc mô hình ngôn ngữ có xu hướng tổng hợp từ dữ liệu huấn luyện mà thường bỏ qua các tác vụ phức tạp, lặp lại và không thể đoán trước như xử lý sự cố, tối ưu truy vấn, quản lý quyền và phản hồi ngay lập tức. Vì vậy, nếu chỉ dựa vào mô tả của AI, người quản lý hoặc nhà phát triển có thể low估 DBA的工作量，导致资源分配不足或对系统可靠性产生误判。 Bài học là cần kiểm chứng các mô tả tự động bằng dữ liệu thực tế từ trường, đặc biệt là khi lên kế hoạch nhân lực, định nghĩa SLA hoặc đánh giá công cụ tự động hoá cho quản trị cơ sở dữ liệu.

Bài viết này giúp bạn thấy được sự khác biệt giữa quan niệm lý tưởng và thực tế công việc của một DBA, từ đó hiểu thách thức thực sự trong quản lý cơ sở dữ liệu.

Beautiful T-SQL Queries: Three Could Delete the Company

T-SQL đẹp mắt không đồng nghĩa với chính xác. Trong 30 năm qua, ngành công nghệ vẫn thường xem xét thẩm mỹ code như một bằng chứng pháp lý đáng tin cậy.

Lập trình viên nên đọc bài này để hiểu cách viết T-SQL đẹp mắt, hiệu quả và dễ đọc—một kỹ năng quan trọng giúp code dễ bảo trì, dễ debug và làm tăng hiệu suất làm việc trong nhóm.

Does anyone run Postgres without PgBouncer?

Hầu hết các nhà cung cấp Postgres lớn (AWS RDS, Azure, Google Cloud SQL, Supabase, Neon...) đều tích hợp sẵn PgBouncer hoặc giải pháp pooling tương tự, chỉ trừ IBM Cloud và Oracle OCI. Bài viết cho rằng pooling là yếu tố bắt buộc vì Postgres xử lý kết nối kém hiệu quả, trái ngược với MySQL hay MongoDB vốn không cần giải pháp bổ sung.

Là lập trình viên quản lý cơ sở dữ liệu PostgreSQL, bạn nên đọc bài này để hiểu tại sao việc sử dụng PgBouncer không chỉ là một giải pháp hiệu quả mà còn là một công cụ bắt buộc để tối ưu hóa hiệu suất, tránh tình trạng "connection leak" và giảm chi phí tài nguyên khi làm việc với nhiều ứng dụng đồng thời.