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
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 |
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 |