``` PgFirstAid: PostgreSQL 函数,用于提高稳定性和性能 ```
PgFirstAid: PostgreSQL function for improving stability and performance

原始链接: https://github.com/randoneering/pgFirstAid

## pgFirstAid:秒速PostgreSQL健康检查 pgFirstAid是一个免费、开源的PostgreSQL函数,旨在快速识别和优先处理数据库健康问题——即使对于没有丰富DBA经验的用户也是如此。它受SQL Server的FirstResponderKit启发,是一个单独的SQL函数,无需外部工具或配置。 运行`SELECT * FROM pg_firstAid();`将提供一个优先排序的检查列表(从关键到信息),涵盖诸如缺少主键、过时的统计信息、表膨胀和连接数等领域。每个问题都包含清晰的描述、建议的操作以及指向官方PostgreSQL文档的链接。 pgFirstAid是只读的,可安全用于生产环境,并且通常在不到一秒钟内执行完毕。它与PostgreSQL 10+(以及在15+上测试过)兼容,并且适用于各种PostgreSQL兼容数据库。用户可以按严重程度或类别过滤结果,以进行重点分析。 它是在日常健康检查、部署前验证、更改后验证以及性能故障排除方面的宝贵工具。请记住先在非生产环境中测试建议!

Hacker News 新闻 | 过去 | 评论 | 提问 | 展示 | 招聘 | 提交 登录 PgFirstAid: PostgreSQL 函数,用于提高稳定性和性能 (github.com/randoneering) 12 分,yakshaving_jgt 发表于 2 小时前 | 隐藏 | 过去 | 收藏 | 1 条评论 netcraft 发表于 31 分钟前 [–] 非常好!你考虑过将其制作成视图吗?只是好奇你为什么不能这样做。回复 指南 | 常见问题 | 列表 | API | 安全 | 法律 | 申请 YC | 联系 搜索:
相关文章

原文

Easy-to-deploy, open source PostgreSQL function that provides a prioritized list of actions to improve database stability and performance.

Inspired by Brent Ozar's FirstResponderKit for SQL Server, pgFirstAid is designed for everyone to use—not just DBAs! Get actionable health insights from your PostgreSQL database in seconds.

  • Zero Dependencies - Single SQL function, no external tools required
  • Comprehensive Checks - 12 (and growing!) built-in health checks covering critical performance and stability issues
  • Prioritized Results - Issues ranked by severity (CRITICAL → HIGH → MEDIUM → LOW → INFO)
  • Actionable Recommendations - Each issue includes specific remediation steps
  • Documentation Links - Direct links to official PostgreSQL documentation for deeper learning
-- Copy and paste the function definition into your PostgreSQL database
-- Then run it:
SELECT * FROM pg_firstAid();

That's it! No configuration needed. Deploy as a user with the highest possible priviledges (in your environment) to avoid issues.

severity category check_name object_name issue_description current_value recommended_action documentation_link
CRITICAL Table Structure Missing Primary Key public.users Table missing a primary key... No primary key defined Add a primary key or unique constraint... https://www.postgresql.org/...
HIGH Statistics Missing Statistics public.orders Table has never been analyzed... Last analyze: Never Run ANALYZE on this table... https://www.postgresql.org/...
  1. Missing Primary Keys - Tables without primary keys that can cause replication issues and poor performance
  2. Unused Large Indexes - Indexes consuming significant disk space but never used (>10MB, 0 scans)
  1. Table Bloat - Tables with >20% bloat affecting performance (tables >100MB)
  2. Missing Statistics - Tables never analyzed, leaving the query planner without statistics
  3. Duplicate Indexes - Multiple indexes with identical or overlapping column sets
  1. Outdated Statistics - Table statistics older than 7 days with significant modifications
  2. Low Index Efficiency - Indexes with poor selectivity (scan-to-tuple ratio >1000)
  3. Excessive Sequential Scans - Tables with high sequential scan activity that may benefit from indexes
  4. High Connection Count - More than 50 active connections potentially impacting performance
  1. Missing Foreign Key Indexes - Foreign key constraints without supporting indexes for efficient joins
  1. Database Size - Current database size and growth monitoring
  2. PostgreSQL Version - Version information and configuration details
-- Show only critical issues
SELECT * FROM pg_firstAid() WHERE severity = 'CRITICAL';

-- Show critical and high priority issues
SELECT * FROM pg_firstAid() WHERE severity IN ('CRITICAL', 'HIGH');
-- Focus on index-related issues
SELECT * FROM pg_firstAid() WHERE category LIKE '%Index%';

-- Check table maintenance issues
SELECT * FROM pg_firstAid() WHERE category = 'Table Maintenance';
SELECT severity, COUNT(*) as issue_count
FROM pg_firstAid()
GROUP BY severity
ORDER BY MIN(CASE severity
    WHEN 'CRITICAL' THEN 1
    WHEN 'HIGH' THEN 2
    WHEN 'MEDIUM' THEN 3
    WHEN 'LOW' THEN 4
    ELSE 5 END);
  • Daily - Quick health check as part of morning routine
  • Before Deployment - Catch potential issues before they impact production
  • After Major Changes - Verify database health after schema modifications or data migrations
  • Performance Troubleshooting - First step when investigating slow queries or system issues
  • Capacity Planning - Regular monitoring to track database growth trends

Read Before Acting

  • Always review recommendations carefully before making changes. I have been supporting Postgres databases for close to a decade, but I learn something new each day
  • Test in a non-production environment first
  • Some operations (like VACUUM FULL) require maintenance windows
  • Never drop an index without validating its usage patterns over time

Permissions

  • Requires read access to system catalogs (pg_catalog)
  • Works with standard user permissions for most checks
  • Some checks may return fewer results for non-superuser accounts

pgFirstAid is designed to be lightweight and safe to run on production systems:

  • Read-only operations (no modifications to your data or schema)
  • Uses system catalog views that are already cached
  • Typical execution time: <1 second on most databases
  • No locking or blocking of user queries
  • PostgreSQL 10+ - Fully supported, but only testing on 15+. This will change as versions are deprecated
  • PostgreSQL 9.x - Most features work (minor syntax adjustments may be needed)
  • Works with all PostgreSQL-compatible databases (Amazon RDS, Aurora, Azure Database, etc.)

Found a bug? Have an idea for a new health check? Let me know! I want this to grow to be a tool that is available for all, accidental DBA or not.

GPLv3

Inspired by Brent Ozar's FirstResponderKit for SQL Server. Thank you to the SQL Server community for pioneering accessible database health monitoring!

Dave-IYKYK


Made with ☕ for the PostgreSQL and Open Source community

联系我们 contact @ memedata.com