"Giulio Cesare Solaroli" <giulio.cesare@gmail.com> writes: > As you may notice, the commit phase takes almost 2 full minutes. :-( Yow. It's hard to believe that the actual commit (ie, flushing the commit record to WAL) could take more than a fraction of a second. I'm thinking there must be a pile of pre-commit work to do, like a lot of deferred triggers. Do you use deferred foreign keys? If so, the most likely bet is that the DELETE is triggering a lot of deferred FK checks, and these are slow for some reason (maybe another missing index). regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 4: Have you searched our list archives? http://archives.postgresql.org

"Giulio Cesare Solaroli" <giulio.cesare@gmail.com> writes: > How can I try to isolate the trigger taking so long, in oder to > understand which is/are the missing index(es)? Try SET CONSTRAINTS ALL IMMEDIATE and then EXPLAIN ANALYZE the delete. This should cause all the triggers to run within the scope of the EXPLAIN ANALYZE, and you'll be able to see which one(s) are slow. (This assumes you're running a recent release of PG; I think EXPLAIN shows trigger times since 8.1 or so.) regards, tom lane ---------------------------(end of broadcast)--------------------------- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match