Find and fix slow Odoo queries

A slow Odoo screen is usually a slow query behind it. With MCP connected, you find it and fix it by asking, in the same chat where you write the rest of your work.

This page walks one loop end to end. You do not type tool names. You ask in plain language, and your assistant picks the tools.

1. Find the slow query

Ask:

Find my slowest queries on the production instance.

Your assistant reads pg_stat_statements and ranks the heaviest queries by total time. It tells you which ones cost the most across the day, not just which one was slow once. Ask it to sort by mean time instead if you are chasing a single slow page rather than overall load.

2. Read the plan

Pick a query and ask:

Why is that one slow? Show me the plan.

Your assistant runs EXPLAIN and reads the plan with you. A sequential scan over a large table, a sort that spills to disk, or a join with no index usually stands out here. You see the cause instead of guessing at it.

3. Check the indexes

Ask:

Is there a missing index for this?

get_index_health reports tables that are scanned without an index, unused indexes that only cost you on writes, duplicates, and Odoo relation fields (the many2one links) that have no index. For a slow filter or a slow related field, this is usually where the answer is.

4. Add the index

Ask:

Add the index for it.

Your assistant builds the index online with CREATE INDEX CONCURRENTLY, so the table is not locked and Odoo keeps serving. The build runs in the background and your assistant checks back until it is ready. If you ever want to undo a drop_index, the recreate SQL comes back with it.

Tip

For a field in a custom module you are building, the better fix is often index=True on the field in your code, so the index is part of the module. Ask your assistant which it recommends. For a one-off on a field you do not control, the online index is the quick win.

5. See what is happening right now

When Odoo stalls mid-import or a screen hangs, ask:

What is running on the database right now?

get_running_statements shows live activity from pg_stat_activity: the long-runners, anything stuck idle in a transaction, and which statement is blocking which. It is read-only. It shows you the blocking process so you can act on it from the dashboard, rather than guessing.

6. Tune the server

If the whole database feels slow rather than one query, the fix may be PostgreSQL itself. Ask:

Is PostgreSQL tuned for this server?

Your assistant reads the current configuration. To re-fit it to the server’s CPU and RAM, use Auto-Tune in your server settings, or ask the assistant to change a specific parameter. Either way, Cloudpepper validates the change before applying it and rolls back automatically if PostgreSQL will not start, so a bad value cannot take the database down.

Working on your own modules

Point your assistant at the custom modules you are developing and run the same loop against your live database. Because it reads your real schema and data, the advice fits your app: a slow ORM call, a query that should be batched, an index you forgot. You catch it while you are still writing the code, not after a customer reports it.

Where to go next

• Tool reference for the full surface.
• Connect Claude or Codex if you have not set it up yet.