| # | Name | Goal ▲ | Type | Data source | Last update | License | |
|---|---|---|---|---|---|---|---|
| 861 | FILLFACTOR is probably too small | This query identifies base tables with a FILLFACTOR setting below 90, flagging them for potentially inefficient storage utilization. While a low FILLFACTOR is intended to accommodate UPDATEs, an excessively low value can lead to wasted disk space and reduced data density, negatively impacting the performance of operations like full table scans. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:10 | MIT License | View |
| 862 | Perhaps multiple surrogate keys | This query identifies base tables with a potentially redundant key structure. It specifically targets those having more than one PRIMARY KEY or UNIQUE constraint defined on a single integer-type column whose name matches the surrogate key naming convention (id_* or *_id). This pattern is a strong indicator of multiple surrogate keys for the same entity, which can indicate an overcomplicated data model. A single entity should typically have only one system-generated identifier to maintain schema clarity, simplify join logic, and avoid redundancy. The presence of multiple such keys warrants a review to determine if one is superfluous. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 11:37 | MIT License | View |
| 863 | Multiple simple keys with integer values | This query identifies base tables with a potentially redundant key structure, specifically those having more than one PRIMARY KEY or UNIQUE constraint defined on a single integer-type column. This pattern may suggest the presence of multiple surrogate keys for the same entity, which can indicate overcomplicated data model. A single entity should typically have only one system-generated identifier to maintain schema clarity, simplify join logic, and avoid redundancy. The presence of multiple such keys warrants a review to determine if one is superfluous. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 11:35 | MIT License | View |
| 864 | FILLFACTOR is probably too big | This query identifies base tables with a potentially suboptimal FILLFACTOR setting, targeting those that likely undergo UPDATE operations. A high FILLFACTOR on such tables can lead to poor performance by reducing the likelihood of Heap-Only Tuple (HOT) updates. When a new row version cannot be stored on the same page as the old version, all indexes on the table must be updated with the new tuple's location. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:08 | MIT License | View |
| 865 | FILLFACTOR is probably too small (2) | This query identifies base tables with a suboptimal FILLFACTOR setting, specifically targeting tables that are heuristically identified as junction tables in a many-to-many relationship. A table is considered a probable junction table if it primarily consists of foreign and primary key columns, with no additional data columns that would suggest UPDATE operations. For these tables, the workload is almost exclusively INSERT and DELETE. Therefore, a FILLFACTOR below 100 serves no performance benefit and results only in wasted storage space and reduced data density. The job of these linking tables is simple: you add a line to connect two things, or you remove the line to disconnect them. You almost never change a line that's already there. The fillfactor setting is used to leave empty space for changes. |
Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-10 09:13 | MIT License | View |
| 866 | Boolean state columns missing default values | This query identifies boolean columns in base tables that lack a default value, but whose names suggest they implement a state machine or act as state flags. In good database design, such boolean state indicators should typically have a default value (false or true) to ensure a predictable initial state when new records are created. | Problem detection | INFORMATION_SCHEMA only | 2026-05-26 07:30 | MIT License | View |
| 867 | B-tree index fillfactor has been explicitly set to 90 | This query identifies B-tree indexes where the FILLFACTOR has been explicitly set to 90. Since 90 is the default FILLFACTOR for B-tree indexes in PostgreSQL, this explicit declaration is superfluous. Removing such redundant settings simplifies the schema definition, improves maintainability, and makes intentionally non-default configurations more apparent. | Problem detection | system catalog base tables only | 2025-11-10 09:15 | MIT License | View |
| 868 | One true lookup table | This query identifies central classifier (reference) tables that store all or most of the system's reference values, along with the dependent tables that reference them. | Problem detection | system catalog base tables only | 2026-05-17 00:00 | MIT License | View |
| 869 | CHECK constraints on columns with personal names | This query identifies CHECK constraints applied to base or foreign table columns that store personal names. It flags these constraints for review to ensure they are not overly strict. Many regular expressions or character limits fail to account for the complexity of real-world names (such as those containing apostrophes, hyphens, or diacritics), thereby inadvertently preventing the registration of valid legal names. | General | INFORMATION_SCHEMA only | 2026-06-03 12:10 | MIT License | View |
| 870 | CHECK constraints on TIMESTAMPTZ and TSTZRANGE columns that do not explicitly specify a time zone | This query identifies CHECK constraints on TIMESTAMPTZ and TSTZRANGE columns that use timestamp literals with fixed UTC offsets instead of named time zones. This practice is flagged as a design flaw because fixed offsets do not account for Daylight Saving Time (DST), leading to constraints on both single timestamps and range boundaries that are unable to correctly represent a local time zone's rules throughout the entire year. | Problem detection | INFORMATION_SCHEMA only | 2025-11-19 16:31 | MIT License | View |
| 871 | Superfluous IS NULL checks in constraints | This query identifies CHECK constraints that contain redundant logic for handling NULLs, a pattern often arising from a misunderstanding of SQL's three-valued logic (TRUE, FALSE, UNKNOWN). A CHECK constraint's condition only fails on FALSE, implicitly permitting NULLs by evaluating comparisons to UNKNOWN. Consequently, an explicit OR column IS NULL clause is tautological and adds no functional value, as demonstrated by the equivalence of CHECK (price IS NULL OR price > 0) and CHECK (price > 0). Removing this superfluous logic improves constraint clarity and eliminates a marginal but unnecessary computational step. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-15 10:19 | MIT License | View |
| 872 | Incorrect use of non-deterministic functions in CHECK constraints | This query identifies CHECK constraints that use non-deterministic time functions (such as now or current_date) in a way that causes initially valid data to become invalid over time. For example, a constraint like localtimestamp(0) > end_date is an anti-pattern because advancing time will eventually violate it. However, safe implementations—such as birth_date < CURRENT_DATE—are permitted, because once the condition is met, it remains true indefinitely as time moves forward. | Problem detection | INFORMATION_SCHEMA only | 2026-06-01 15:37 | MIT License | View |
| 873 | Classifier tables without a name column | This query identifies classifier (reference data) tables that do not contain a name column. Since the primary purpose of a reference table is to provide human-readable labels for standardized codes, lacking a name column often indicates an incomplete database design. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2026-05-29 15:47 | MIT License | View |
| 874 | Oversized classifier code data types | This query identifies classifier tables where the code column uses a data type that accommodates unnecessarily large values for reference data. Specifically, it flags code columns defined as integer, bigint, or varchar(n) where n > 10. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2026-05-29 15:53 | MIT License | View |
| 875 | Excessive classifier name length | This query identifies classifier tables where the name column allows strings longer than 100 symbols. Such long names are difficult to read and can cause layout issues in the user interface. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2026-05-05 17:31 | MIT License | View |
| 876 | Columns with array or user-defined type | This query identifies columns defined with complex data types, specifically Arrays or User-Defined Types (UDTs). While PostgreSQL supports these advanced features, their indiscriminate use often signals an over-engineered schema. The query serves as a prompt to audit these columns and verify that the complex type is strictly necessary for performance or domain logic, and that a standard relational structure (e.g., scalar types or a child table) would not be a more appropriate and flexible design choice. | General | system catalog base tables only | 2025-12-12 17:23 | MIT License | View |
| 877 | Age columns in base and foreign tables | This query identifies columns in base and foreign tables that are intended to store age values. It detects these fields by analyzing both their naming conventions and data types. | Problem detection | INFORMATION_SCHEMA only | 2026-05-15 14:57 | MIT License | View |
| 878 | Registration/modification time is optional | This query identifies columns intended to store registration or modification timestamps that are currently defined as optional (nullable). Since creation and update times are crucial for data auditing, these columns should typically have a NOT NULL constraint. | Problem detection | INFORMATION_SCHEMA only | 2026-05-09 12:56 | MIT License | View |
| 879 | Too generic names regarding persons and their names (columns of derived tables) | This query identifies columns in views (derived tables) whose names suggest they store a person's name but lack context about the person's role. In a view, a column containing a person's name should indicate their specific role regarding the entity. For example, a column simply named surname in an active_product view is ambiguous; a more descriptive name, such as registrar_surname, is preferred. However, if the primary purpose of the view is to present personal data, generic names like surname are perfectly acceptable. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2026-05-15 15:46 | MIT License | View |
| 880 | Range lower bound can be NULL | This query identifies columns of base tables that use a RANGE data type but are configured to permit a NULL lower bound. This highlights ranges that can be "unbounded" on their starting side, which may be unintentional and could impact query logic and data constraints. | Problem detection | INFORMATION_SCHEMA+system catalog base tables | 2025-11-07 12:03 | MIT License | View |