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

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 10 of 33 | next ›
Discussion Overview
grouppgsql-performance @
categoriespostgresql
postedApr 26, '13 at 2:33a
activeJul 13, '13 at 9:29p
posts33
users10
websitepostgresql.org
irc#postgresql

People

Translate

site design / logo © 2021 Grokbase