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.
>> 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
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 plann
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. W
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 o
"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
>> 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
"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
>> 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 t
