- Batch index existence checks into single query (16+ queries -> 1 query)
- Batch timestamp column checks into single query (8 queries -> 1 query)
- Batch field length checks into single query (5 queries -> 1 query)
Performance improvement: ~70-80% faster initialization (35s -> 5-10s)
Key optimizations:
1. check_tables(): Use ANY($1) to check all indexes at once
2. _migrate_timestamp_columns(): Batch all column type checks
3. _migrate_field_lengths(): Batch all field definition checks
All changes are backward compatible with no schema or API changes.
Reduces database round-trips by batching information_schema queries.
• Add DocStatus.PREPROCESSED enum value
• Update API routes and response models
• Add preprocessed filter in web UI
• Update localization files
• Handle preprocessed status in deletion
• Uses exact versions from `bun.lock` without updating
• Skips devDependencies, saving time and bandwidth
• The --emptyOutDir already configured in vite.config.ts
- Changed create_entity to use rag.acreate_entity() instead of direct graph manipulation
- Changed create_relation to use rag.acreate_relation() instead of direct graph manipulation
- This ensures vector embeddings are created and entities/relations are searchable
- Adds proper concurrency locks and metadata population
Added three new REST API endpoints for direct knowledge graph manipulation:
- POST /graph/entity/create: Create new entities in the knowledge graph
- POST /graph/relation/create: Create relationships between entities
- POST /graph/entities/merge: Merge duplicate/misspelled entities while preserving relationships
The merge endpoint is particularly useful for consolidating entities discovered after document processing, fixing spelling errors, and cleaning up the knowledge graph. All relationships from source entities are transferred to the target entity, with intelligent handling of duplicate relationships.
Updated API documentation in lightrag/api/README.md with usage examples for all three endpoints.
Prepared statement caching is disabled by setting
`statement_cache_size=0` in the `asyncpg` connection pool parameters.
This is necessary to prevent
`asyncpg.exceptions.InvalidSQLStatementNameError` when using
transaction-level connection poolers like Supabase Supavisor or
pgbouncer, which do not support prepared statements.