On Wed, Nov 03, 2004 at 03:53:16PM -0500, Andrew Sullivan wrote:
> and may bust your query out of the cache. Also, we'd need some more
Uh, the data you're querying, of course. Queries themselves aren't
cached.
A
--
Andrew Sullivan | [EMAIL PROTECTED]
I remember when computers were frustratin
If your running Linux, and kernel 2.6.x, you can try playing with the:
/proc/sys/vm/swappiness
setting.
My understanding is that:
echo "0" > /proc/sys/vm/swappiness
Will try to keep all in-use application memory from being swapped out
when other processes query the disk a lot.
Although, since
Thanks - this is what I was afraid of, but I may have to do this
Is there a good way to monitor what's in the cache?
j
<[EMAIL PROTECTED]> writes:
> The caching appears to disappear overnight.
You've probably got cron jobs that run late at night and blow out your
kernel disk cache by accessing
On Wed, Nov 03, 2004 at 01:19:43PM -0700, [EMAIL PROTECTED] wrote:
> The caching appears to disappear overnight. The environment is not in
> production yet so I'm the only one on it.
Are you vacuuming at night? It grovels through the entire database,
and may bust your query out of the cache. Al
<[EMAIL PROTECTED]> writes:
> The caching appears to disappear overnight.
You've probably got cron jobs that run late at night and blow out your
kernel disk cache by accessing a whole lot of non-Postgres stuff.
(A nightly disk backup is one obvious candidate.) The most likely
solution is to run s
ailto:[EMAIL PROTECTED] On Behalf Of Andrew Sullivan
Sent: Wednesday, November 03, 2004 12:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [PERFORM] preloading indexes
On Wed, Nov 03, 2004 at 12:12:43PM -0700, [EMAIL PROTECTED] wrote:
> That's correct - I'd like to be able to keep particu
<[EMAIL PROTECTED]> writes:
> I am working with some pretty convoluted queries that work very slowly the
> first time they're called but perform fine on the second call. I am fairly
> certain that these differences are due to the caching. Can someone point me
> in a direction that would allow me to
--
uh, you can always load a table in cache by doing a seq scan on it...
like select count(1) from table or something... this doesn't work for
indexes of course, but you can always look in the system catalogs, find
the filename for the index, then just open() it from an external program
On Wed, Nov 03, 2004 at 12:12:43PM -0700, [EMAIL PROTECTED] wrote:
> That's correct - I'd like to be able to keep particular indexes in RAM
> available all the time
If these are queries that run frequently, then the relevant cache
will probably remain populated[1]. If they _don't_ run frequently,
Title: Message
That’s correct – I’d
like to be able to keep particular indexes in RAM available all the time
The best way to get all the stuff needed
by a query into RAM is to run the query. Is it more that you want to
'pin' the data in RAM so it doesn't get overwritten by other quer
D] On Behalf Of
[EMAIL PROTECTED]Sent: 03 November 2004
17:31To: [EMAIL PROTECTED]Subject:
[PERFORM] preloading indexes
I am working with some pretty
convoluted queries that work very slowly the first time they’re called but
perform fine on the second call. I am fairly certain that th
I am working with some pretty convoluted queries that work
very slowly the first time they’re called but perform fine on the second
call. I am fairly certain that these differences are due to the caching. Can
someone point me in a direction that would allow me to pre-cache the critical
inde
12 matches
Mail list logo
