Re: Strange nested loop for an INSERT

phb07 <phb07(at)apra(dot)asso(dot)fr> 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