Skip to content

Conversation

@tjgreen42
Copy link
Collaborator

Summary

Details

The registry previously used TP_MAX_INDEXES=64 fixed array. This caused "registry full" errors with many indexes, especially partitioned tables.

The new dshash implementation:

  • No fixed limit (bounded only by available memory)
  • O(1) lookup performance
  • Uses existing DSA infrastructure

Also fixes the object access hook which was skipping cleanup for PERFORM_DELETION_INTERNAL drops, causing registry entries to leak on cascade operations.

Testing

  • All 10 SQL regression tests pass
  • Verified 100 create/drop cycles work (beyond old 64-slot limit)
  • Extended dropped.sql tests for create-drop-recreate cycles

Fixes #83

The registry previously used a fixed-size array (TP_MAX_INDEXES=64) to
track index OIDs to shared state mappings. This caused "registry full"
errors when creating many indexes, especially with partitioned tables.

This change replaces the fixed array with a dshash (dynamic shared hash
table) that:
- Has no fixed limit on number of indexes (bounded only by memory)
- Provides O(1) lookup performance
- Uses the same DSA infrastructure already used elsewhere

Also fixes the object access hook to properly clean up on cascade drops
(e.g., DROP TABLE dropping its indexes). The previous check for
PERFORM_DELETION_INTERNAL skipped cleanup for these cases, causing
registry entries to leak.
@tjgreen42 tjgreen42 merged commit 0ea1a54 into main Dec 28, 2025
11 checks passed
@tjgreen42 tjgreen42 deleted the dshash-registry branch December 28, 2025 19:31
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Registry slots not freed when BM25 indexes are dropped

2 participants