Re: Why are these ARC variables per-backend?

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Why are these ARC variables per-backend?
Дата
Msg-id 27537.1082401091@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Why are these ARC variables per-backend?  (Jan Wieck <JanWieck@Yahoo.com>)
Ответы Re: Why are these ARC variables per-backend?  (Jan Wieck <JanWieck@Yahoo.com>)
Re: Why are these ARC variables per-backend?  (Kenneth Marshall <ktm@it.is.rice.edu>)
Список pgsql-hackers
Jan Wieck <JanWieck@Yahoo.com> writes:
> Tom Lane wrote:
>> I've got a problem with these variables in freelist.c:
>> 
>> static int        strategy_cdb_found;
>> static int        strategy_cdb_replace;

> These two most definitely are per backend because they hold status 
> information about the blocks this backend specifically is mucking with. 
> If it all would be in one function, they would be local variables.

Would you object if I made 'em actual local variables?  This would
clutter the strategy API slightly since the vars would have to be passed
out of some routines and into others, but I think it would be logically
cleaner.  (In the back of my mind is the idea to support two instances
of the ARC datastructure, one for global and one for local buffers, so
minimizing the number of static variables is a prerequisite.)
>> static int        strategy_get_from;

> This one is questionable. The point of it is to steer the T1/T2 list 
> sizes towards the goal of the strategy (T1_target). It doesn't matter 
> much if this is off by one every now and then, it will be corrected at 
> the next buffer eviction ... or the one after that.

Why do we have it at all?  Seems like it would be at least as good to
make the T1-or-T2 decision in StrategyGetBuffer, rather than earlier.
        regards, tom lane


В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Magnus Hagander"
Дата:
Сообщение: Postgresql snapshots broken?
Следующее
От: Andrew Sullivan
Дата:
Сообщение: Re: signal 11 on AIX: 7.4.2