Re: In progress INSERT wrecks plans on table

From: mark(dot)kirkwood(at)catalyst(dot)net(dot)nz
To: "Thomas Kellerer" <spam_eater(at)gmx(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: In progress INSERT wrecks plans on table
Date: 2013-05-02 22:59:31
Message-ID: 9d1267f54ba06afd4624ac8dae787222.squirrel@mail.catalyst.net.nz
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> mark(dot)kirkwood(at)catalyst(dot)net(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2013-05-02 23:07:20 Re: 9.3 Beta1 status report
Previous Message Josh Berkus 2013-05-02 22:58:00 Re: matview niceties: pick any two of these three

Browse pgsql-performance by date

  From Date Subject
Next Message Mike McCann 2013-05-02 23:11:15 Hardware suggestions for maximum read performance
Previous Message Thomas Kellerer 2013-05-02 22:32:20 Re: In progress INSERT wrecks plans on table