Re: [HACKERS] relation cache statistics (was: -HEAD planner issue wrt hash_joins on dbt3 ?)

2006-09-17 Thread Jim C. Nasby
On Mon, Sep 18, 2006 at 12:20:10AM -0400, Tom Lane wrote: > "Jim C. Nasby" <[EMAIL PROTECTED]> writes: > > I think it'd be better to attack this problem from the "other side"; > > namely looking at what's actually cached. > > You can kiss goodbye to plan stability if you go that route... and > in

Re: [HACKERS] relation cache statistics (was: -HEAD planner issue wrt hash_joins on dbt3 ?)

2006-09-17 Thread Tom Lane
"Jim C. Nasby" <[EMAIL PROTECTED]> writes: > I think it'd be better to attack this problem from the "other side"; > namely looking at what's actually cached. You can kiss goodbye to plan stability if you go that route... and in any case I doubt the assumption that what's in shared buffers is repre

[HACKERS] relation cache statistics (was: -HEAD planner issue wrt hash_joins on dbt3 ?)

2006-09-17 Thread Jim C. Nasby
On Sun, Sep 17, 2006 at 04:18:36PM -0400, Tom Lane wrote: > * table and index. (Ideally other_pages should include all the other > * tables and indexes used by the query too; but we don't have a good way > * to get that number here.) > > A first-order approximation to this would be to add up t