From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | "Ross J(dot) Reedstrom" <reedstrm(at)rice(dot)edu> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: again on index usage |
Date: | 2002-01-11 18:30:53 |
Message-ID: | 200201111830.g0BIUrR26824@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > That is on our TODO list, at least.
> >
>
> Hmm, on Linux this sort of behavior (skip the pg buffers for sequential
> scans) would have interesting load senstive behavior: since Linux uses
> all not-otherwise in use RAM as buffer cache, if you've got a low-load
> system, even very large tables will be cached. Once other processes start
> competing for RAM, your buffers go away. Bruce, what does xBSD do?
FreeBSD does, NetBSD will soon, not sure about the others. I believe
NetBSD will be tunable because page cache vs. i/o cache is not always
best done with a FIFO setup.
Also, when we pull from the kernel cache we have to read into our shared
buffers; much faster than disk i/o but slower than if they were already
in the cache. For me the idea of doing non-cached sequential scans came
from a Solaris internals book I was reading. I think it will be
possible to mark large sequential scan buffer i/o with lower priority
caching that may help performance. However, if others are also doing
sequential scans of the same table _only_, our normal caching may be
best. As you can see, this gets quite complicated and I am doubtful
there will be a general solution to this problem --- more of a feedback
loop may be the best bet --- determine which sequential scans are wiping
the cache with little other purpose and start not caching them.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | mlw | 2002-01-11 18:58:09 | Re: again on index usage |
Previous Message | Bruce Momjian | 2002-01-11 18:24:20 | Re: again on index usage |