Re: [Firebird-devel] AutoOptimize

[Vlad H. <hv...@us...>]

> >>>     So the question i want to ask - is anybody have good idea of how to rule
> >>> thread IO priority ? What i want to know is how to rule amount of thread IO 
> >>> requests so that particular thread don't eat many resources when other threads
> >>> have what to do
> >> As far as I know, linux not long ago started experiments with 
> >> process-level IO priority:
> >>
> >> http://www.die.net/doc/linux/man/man1/ionice.1.html
> > 
> >     We need platform-independent solution
> >  
> 
> Yes, and if you have read the link it sets IO priority only for a 
> process, not thread. Not enough for us.

    Yes, i've read it
 
> >> I.e., if we mark some thread as low IO priority, we may delay IO requests from it 
> > 
> > 
> >     How much delay ? This is a central point
> > 
> 
> As a first approach we may delay them as long as there are other active 
> disk requests.

    This is not good, imo. Such low-priority thread will always sleep if we have even 
small but regular IO load, i guess. 
 
...
> Telling true, we have made a lot of efforts to make fb 2.0 to work 
> slower with existing applications:-( And need to use precise index 
> statistics is certainly one of them. We should better fix such things as 
> soon as possible.

    Perhaps

> But adding IO priority control to, for example, 2.0.1 is not a thing I 
> want to agree with. Too serious change for point release, is not it? As 

    Nobody offer to add it into 2.0.1. At least not me ;)

> an opposite we may run statistics auto-update with normal priority. It 

    I see no good reason to implement auto-update index statistics even in 2.1
Until we have histogramms we don't need this feature. IMO, of course
>From the another POV - it is good to have for PR :)

> seems it will not break whole system throughput as much as bad plans do 

    It depends. Yes, our indices are very dense and we need smaller IO to read 
leaf level compared to other DBMS, but it is very CPU intensive. 

> now. Anyway for future versions (remember prepared statements cache ?) 
> it will require more common solution.

    My current worries is cache_writer and garbage_collector threads

Regards,
Vlad