phb07 <phb07@xxxxxxxxxxxx> writes: > The performance issue, encountered in very specific situations, is the > time needed to cancel a significant number of insertions. > I have build a simple test case that reproduces the problem without the > need of the extension. It just mimics the behaviour. At least for this example, the problem is that the DELETE enormously alters the statistics for the t1_log.tuple column (going from 100% "NEW" to 50% "NEW" and 50% "OLD"), but the plan for your last command is generated with stats saying there are no "OLD" entries. So you get a plan that would be fast for small numbers of "OLD" entries, but it sucks when there are lots of them. The fix I would recommend is to do a manual "ANALYZE t1_log" after such a large data change. Auto-ANALYZE would fix it for you after a minute or so, probably, but if your script doesn't want to wait around then an extra ANALYZE is the ticket. regards, tom lane -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
