0

Foreign key indexes are never used as you can see in pg_stat_user_indexes table. I want to remove them. Are there any disadvantages of removing foreign keys indexes due to non-usage.

db=# SELECT * FROM pg_stat_user_indexes WHERE relname='order_cancellationreason';
     relid | indexrelid | schemaname |         relname          |                indexrelname                 | idx_scan | idx_tup_read | idx_tup_fetch 
    -------+------------+------------+--------------------------+---------------------------------------------+----------+--------------+---------------
     29835 |      31055 | public     | order_cancellationreason | order_cancellationreason_address_id         |        0 |            0 |             0
     29835 |      31053 | public     | order_cancellationreason | order_cancellationreason_cancelled_by_id    |        0 |            0 |             0



 db=#\d+ order_cancellationreason
     ...
     Indexes:
        "order_cancellationreason_cancelled_by_id" btree (cancelled_by_id)
        "order_cancellationreason_address_id" btree (address_id)

    Foreign-key constraints:
        "cargo_id_refs_id_f4ffe34d" FOREIGN KEY (cargo_id) REFERENCES cargo_cargoinfo(id) DEFERRABLE INITIALLY DEFERRED
        "order_cancellationreason_address_id_fkey" FOREIGN KEY (address_id) REFERENCES invoice_address(id) DEFERRABLE INITIALLY DEFERRED
        "order_cancellationreason_cancelled_by_id_fkey" FOREIGN KEY (cancelled_by_id) REFERENCES auth_user(id) DEFERRABLE INITIALLY DEFERRED
4

1 回答 1

2

Indexes on the referring foreign key column are not required for referential integrity enforcement. You only need a unique index on the referred-to column for that.

The only downside to removing the index on the referring column is that checks and enforcement can be very slow. If you attempt to delete a row from the FK target table, the database must check whether that value appears in the referring column and either reject the delete or, for ON DELETE CASCADE keys, delete it. Either way, without an index on the referring column this will likely lead to a seqscan. For small referring tables that's fine, but for a big referring table and especially where multiple FK checks are being made, performance can be truly awful.

If your application doesn't ever actually use the FK checks, ie they're there to declare the data model and for peace of mind rather than the expectation that they'll actually be checked and enforced, then removing the referring column index may be fine.

If your app actually performs deletes or updates on the referred-to table, I'd recommend keeping the index.

I haven't verified that FK enforcement checks properly appear in pg_stat_user_indexes. I'd recommend checking that yourself; try running some deletes you know will fail on the referred-to table, and see if the index stats on the referring column change.

于 2013-02-22T02:47:40.417 回答