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
On 11/29/2004 10:49 AM, Greg Stark wrote:
I'll point out other databases end up treading the same ground. Oracle started
with a well defined rules-based system that was too inflexible to handle
complex queries. So they went to a cost-based optimizer much like Postgres's
current optimizer.
One possibility: vacuum already knows how many tuples it removed. We
could set reltuples equal to, say, the mean of the number-of-tuples-
after-vacuuming and the number-of-tuples-before. In a steady state
situation this would represent a fairly reasonable choice. In cases
where the table
Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] 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
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
Zeugswetter Andreas DAZ SD [EMAIL PROTECTED] 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
Tom Lane [EMAIL PROTECTED] writes:
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
Greg Stark [EMAIL PROTECTED] writes:
Tom Lane [EMAIL PROTECTED] writes:
I'm unsure why you feel you need a knob to defeat this.
Simply put because the optimizer isn't infallible.
And one of the main reasons that it's fallible is because it sometimes
uses grossly obsolete statistics. We can
Tom Lane [EMAIL PROTECTED] writes:
Nonsense. You're assuming incremental changes (ie, only a small
fractional change in table size), but we are getting killed by
non-incremental cases. If the plan cost estimates are such that a small
fractional change in table size will cause the planner to
