"Zeugswetter Andreas DAZ SD" <[EMAIL PROTECTED]> writes:
>> rel->pages = RelationGetNumberOfBlocks(relation);
> Is RelationGetNumberOfBlocks cheap enough that you can easily use it for the
> optimizer ?
It's basically going to cost one extra lseek() kernel call ... per
query, per table referenced in the query. I no longer think this is
a killer argument. lseek isn't going to induce any I/O, so it should
be cheap as kernel calls go.
> I myself have always preferred more stable estimates that only change
> when told to. I never liked that vacuum (without analyze) and create index
> change those values, imho only analyze should.
Indeed, this is probably the most significant argument in favor of
leaving things as they are. But the other side of the coin is: why
shouldn't a bunch of inserts or updates cause the plan to change?
The people who are complaining about it have certainly posted plenty
of examples where it would help to change the plans.
> 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.
regards, tom lane
---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match
