Does this issue consistently repeat within a transaction block? Does it still happen if you reverse the tests?
I've run into similar issues in the past, and the problem was often from postgresql checking indexes -- the first test would stall because indexes needed to be read into memory, then the second test would fly. If I waited more than 5 seconds (or outside of a transaction), postgres would lose the indexes from memory. Triggers are likely too, but index issues are often more common. If that's the case, what worked for me: * increasing the cache allocation for postgres * using partial/function indexes on some columns, and adjusted the query to hint against them (otherwise the planner won't use it) * upgrading to postgres 9.6 (searching is a lot better thanks to a few improvements and a new parallel search feature) Something that also worked for me in debugging this sort of stuff was using query-logging in postgres to grab the actual processed query, then running "explain analyze" on it and seeing where the slowdown happened. the only way to clear out the postgres index cache is to stop/start the server , so it can be a pain to get every condition timed right. the results from "explain analyze" often vary wildly from running the query normally with timing on. -- SQLAlchemy - The Python SQL Toolkit and Object Relational Mapper http://www.sqlalchemy.org/ To post example code, please provide an MCVE: Minimal, Complete, and Verifiable Example. See http://stackoverflow.com/help/mcve for a full description. --- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
