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
Date: Mon, 12 Sep 2016 10:41:35 -0400
Message-ID: <25256.1473691295@sss.pgh.pa.us> (raw)
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>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-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
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, phb07@apra.asso.fr
Subject: Re: Strange nested loop for an INSERT
In-Reply-To: <25256.1473691295@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox