Обсуждение: Re: Stopgap solution for table-size-estimate updatingproblem
>> 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. Ok, understood. I just need to make sure I don't "vacuum full" in that case, which is good anyway if I expect the table to soon grow to this size again. I think that is good. I think I recall that lseek may have a negative effect on some OS's readahead calculations (probably only systems that cannot handle an lseek to the next page eighter) ? Do you think we should cache the last value to avoid the syscall ? Andreas
"Zeugswetter Andreas DAZ SD" <ZeugswetterA@spardat.at> writes: > I think I recall that lseek may have a negative effect on some OS's > readahead calculations (probably only systems that cannot handle an > lseek to the next page eighter) ? Do you think we should cache the > last value to avoid the syscall ? We really can't, since the point of doing it is to find out whether any other backends have extended the file since we last looked. Also, IIRC seqscan startup does a similar lseek() anyhow, so having the planner do one will make no difference to the readahead or lack of it in a subsequent seqscan. regards, tom lane