From: Tom Lane <tgl@sss.pgh.pa.us>
To: phb07 <phb07@apra.asso.fr>
cc: pgsql-performance@postgresql.org
Subject: Re: Strange nested loop for an INSERT
In-reply-to: <1f22a3fa-dcc5-eeac-a708-7f10fada4674@apra.asso.fr>
References: 
 <CD1B112115AFCF46A0EB8CFD8EE88B461E2B19D2@FRCRPVV9EX4MSX.ww931.my-it-solutions.net>
 <1f22a3fa-dcc5-eeac-a708-7f10fada4674@apra.asso.fr>
Comments: In-reply-to phb07 <phb07@apra.asso.fr>
	message dated "Mon, 12 Sep 2016 16:15:05 +0200"
Date: Mon, 12 Sep 2016 10:41:35 -0400
Message-ID: <25256.1473691295@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

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


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance