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 reflect
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 so
> > 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
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. I
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
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 settin
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.
> > I
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,
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