On Apr 23, 2008, at 12:31 AM, Greg Smith wrote:
Jim threw out that you can just look at the page hit percentages
instead. That's not completely true. If you've had some nasty
query blow out your buffer cache, or if the server has been up a
looong time and the total stas don't really
Example : let's imagine a cache priority setting.
Which we can presume the DBA will set incorrectly because the tools
needed to set that right aren't easy to use.
LOL, yes.
Jim threw out that you can just look at the page hit percentages
instead. That's not completely true. If
The optimizer could then use a different (much lower) value of
random_page_cost for tables for which cache priority is set
highest since it would know.
cache priority to me sounds like we're trying to influence caching
behavior, which isn't what's happening. I do agree that we
Decibel! wrote:
we can just look at
the hit rate for the object. But we'd also need stats for how often we
find pages for a relation in the OS cache, which no one has come up with
a good method for.
Makes me wonder if we could (optionally, I guess, since timing
stuff is apparently slow on
It started with this query :
EXPLAIN ANALYZE SELECT * FROM relations r JOIN nodes n ON
(n.id=r.child_id) WHERE r.parent_id=16330;
QUERY PLAN
On Apr 22, 2008, at 5:13 AM, PFC wrote:
In order to have it use the fast plan I must set random_page_cost
to 1 which I absolutely don't want to do.
Setting effective_cache_size to huge values has no effect.
If I select a value of parent_id that has much less children, the
index will be used,
On Wed, Apr 23, 2008 at 12:11 AM, Decibel! [EMAIL PROTECTED] wrote:
On Apr 22, 2008, at 5:13 AM, PFC wrote:
In order to have it use the fast plan I must set random_page_cost to 1
which I absolutely don't want to do.
Setting effective_cache_size to huge values has no effect.
If I select
Decibel! [EMAIL PROTECTED] writes:
cache priority to me sounds like we're trying to influence caching
behavior, which isn't what's happening. I do agree that we need a
better way to tell the planner what tables are in memory.
What's been discussed in the past is per-tablespace settings for
On Tue, 22 Apr 2008, PFC wrote:
Example : let's imagine a cache priority setting.
Which we can presume the DBA will set incorrectly because the tools needed
to set that right aren't easy to use.
An alternative would be for the background writer to keep some stats and do
the thing for us :
