phb07 <ph...@apra.asso.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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
