Message-ID: <9d1267f54ba06afd4624ac8dae787222.squirrel@mail.catalyst.net.nz>
In-Reply-To: <kluphf$jn7$1@ger.gmane.org>
References: <5179E77B.7050601@catalyst.net.nz>
	<5179ECC5.2010206@archidevsys.co.nz> <5179F259.3010509@catalyst.net.nz>
	<5179F5C6.8070702@archidevsys.co.nz> <5180E3C8.3010201@catalyst.net.nz>
	<2121.1367417215@sss.pgh.pa.us> <5181B80D.70404@catalyst.net.nz>
	<CA+U5nMKYYZDekhtxz1E1B11dAm9UJoHBQHrB6DiiZDJo3fLd0Q@mail.gmail.com>
	<916bff05a5ab130c76d7835abbaf7762.squirrel@mail.catalyst.net.nz>
	<kluphf$jn7$1@ger.gmane.org>
Date: Fri, 3 May 2013 10:59:31 +1200
Subject: Re: In progress INSERT wrecks plans on table
From: mark.kirkwood@catalyst.net.nz
To: "Thomas Kellerer" <spam_eater@gmx.net>
Cc: pgsql-performance@postgresql.org
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

> mark.kirkwood@catalyst.net.nz wrote on 03.05.2013 00:19:
>> I think the idea of telling postgres that we are doing a load is
>> probably
>> the wrong way to go about this. We have a framework that tries to
>> automatically figure out the best plans...I think some more thought
>> about
>> how to make that understand some of the more subtle triggers for a
>> time-to-do-new-plans moment is the way to go. I understand this is
>> probably hard - and may imply some radical surgery to how the stats
>> collector and planner interact.
>
> I wonder if "freezing" (analyze, then disable autovacuum) the statistics
> for the large number of rows would work.
>
>
>

I'm thinking that the issue is actually the opposite - it is that a new
plan is needed because the new (uncomitted) rows are changing the data
distribution. So we want more plan instability rather than plan stability
:-)

Cheers

Mark


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