From: | Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Jan Wieck <JanWieck(at)Yahoo(dot)com>, pgsql-hackers(at)postgreSQL(dot)org |
Subject: | Re: Why are these ARC variables per-backend? |
Date: | 2004-04-19 19:47:45 |
Message-ID: | 20040419194745.GB22001@it.is.rice.edu |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Apr 19, 2004 at 02:58:11PM -0400, Tom Lane wrote:
> Jan Wieck <JanWieck(at)Yahoo(dot)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.)
I am not sure what changes are in store with the bufmgr locking, but
the concurrency could also benefit from having multiple buffer queues.
This would allow the contention for the locks to be further reduced.
The change to a local variable would also enable that change.
Ken Marshall
From | Date | Subject | |
---|---|---|---|
Next Message | Brett Schwarz | 2004-04-19 20:02:32 | Re: [HACKERS] Why is libpgtcl still in CVS? |
Previous Message | Tom Lane | 2004-04-19 19:21:35 | Re: Why are these ARC variables per-backend? |