refactor: Optimize memory fetching by moving sorting and slicing to DB (PR #1531 remake)

[odilitime]

Resubmit #1531 by @nicky-ru to fix merge conflicts to get it to land

Relates to:

No

---

Risks

Low

• Adjustments to database queries improve performance by moving sorting and limiting logic to the database side.
• Even though this change adds improvements to the Postgres adapter and required a change in the global IDatabaseAdapter, other database adapters are still working because the limit parameter is optional.
• Other plugins relying on the getMemoriesByRoomIds function can opt into the limit functionality, but it is not necessary.
• No breaking changes introduced.

---

Background

What does this PR do?

This PR improves the performance of memory-fetching functionality by:

• Moving sorting and slicing logic from the application layer to the database layer.
• Adding an optional limit parameter to restrict the number of results fetched from the database.
• Adjusting the runtime logic to leverage the new database query functionality.

Why was this change made?

In our database with 60,000 memories, fetching memories by room IDs took 40 seconds, significantly affecting the performance of the agent. After applying this fix, the query execution time dropped to just 0.02 seconds. This improvement was observed using Supabase analytics.

---

What kind of change is this?

Improvements

• Changes to existing functionality to improve database query performance.

---

Documentation changes needed?

My changes do not require a change to the project documentation.

---

Testing

Where should a reviewer start?

• Review the changes in packages/adapter-postgres/src/index.ts to understand how sorting and limiting were implemented in the database query.
• Look at the adjusted runtime logic in packages/core/src/runtime.ts for the integration of the limit parameter.

Detailed testing steps

1. Ensure all existing tests for memory fetching pass.
2. Manually test the memory-fetching feature by:
   • Querying with and without the limit parameter.
   • Verifying that the sorting order (createdAt DESC) is maintained.
3. Monitor query performance with larger datasets to confirm improvements.

---

Database changes

• Updated query logic to include ORDER BY createdAt DESC and optional LIMIT in the PostgreSQL adapter.

---

Discord username

nikita_zhou

---

Screenshots

I will attach screenshots of:

• Successful working run with Postgres and SQLite.
• Successful linting results.

Using Postgres adapter

Using SQLite adapter

Linting