Re: Strange nested loop for an INSERT
От | Tom Lane |
---|---|
Тема | Re: Strange nested loop for an INSERT |
Дата | |
Msg-id | 25256.1473691295@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Strange nested loop for an INSERT (phb07 <phb07@apra.asso.fr>) |
Ответы |
Re: Strange nested loop for an INSERT
|
Список | pgsql-performance |
phb07 <phb07@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
В списке pgsql-performance по дате отправления: