Re: Stopgap solution for table-size-estimate

On Mon, 2004-11-29 at 15:37, Tom Lane wrote:
> "Zeugswetter Andreas DAZ SD" <ZeugswetterA(at)spardat(dot)at> writes:
> > Tom wrote:
> >>> But I am used to applications
> >>> that prepare a query and hold the plan for days or weeks. If you happen to
> >>> create the plan when the table is by chance empty you lost.
> >>
> >> You lose in either case, since this proposal doesn't change when
> >> planning occurs or doesn't occur.
>
> > This is not true in my case, since I only "update statistics"/analyze
> > when the tables have representative content (i.e. not empty).
>
> I'm unsure why you feel you need a knob to defeat this. The only time
> when the plan would change from what you think of as the hand-tuned
> case is when the physical table size is greatly different from what it
> was when you analyzed. The entire point of wanting to make this change
> is exactly that in that situation the plan *does* need to change.

Well, the cutover between plans is supposed to happen at exactly the
right place, so in theory you should want this. The margin for error on
the various estimates means that the actual cutover is often some way
away from the smooth transition point. If you're unlucky enough to have
a plan that fluctuates on either side of the planner's transition point
AND where the transition point is misplaced then you can get a large
discontinuity in execution times. That's when a careful man such as
Andreas can take extra benefit from manual control.

You're both right. We should help both the careful tuner and the
short-of-time-developer.

--
Best Regards, Simon Riggs