> I think we need to more precisely define the problems of our system with
> point in time statistics
> -- no reaction to degree of other concurrent activity
> -- no way to react to abnormal skew that only persists for a very short
> duration
> -- too late reaction to changing distribution (e.g. current date column
> when a new year starts)
>       and the variant: too late adaption when a table is beeing filled
> -- missing cost/selectivity estimates for several parts of the system

How would we manage point-in-time statistics?  How would we collect them & 
store them?   I think this is an interesting idea, but very, very hard  to 
do ...


Josh Berkus
PostgreSQL @ Sun
San Francisco

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
       choose an index scan if your joining column's datatypes do not

Reply via email to