Re: priority on a process

From: "Chris Palmer" <chris(dot)palmer(at)geneed(dot)com>
To: "scott(dot)marlowe" <scott(dot)marlowe(at)ihs(dot)com>, "pg-general (E-mail)" <pgsql-general(at)postgresql(dot)org>
Subject: Re: priority on a process
Date: 2003-05-16 23:09:33
Message-ID: 4DC5F5CE7BA89D40B26FFD9A7982FE25018DC6@mail.geneedinc.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Scott Marlowe writes:

> Yes, effective_cache_size is the postgresql setting that
> tells the postmaster we have "about this much kernel cache"
> on average.
>
> If it's set low, then postgresql assumes the kernel isn't
> caching much, if it's higher, then it assumes it's more
> likely for data to be "in memory"
> and makes index scans more likely than seq scans.
>
> Sorry, I should have pointed out I was talking out about a
> postgresql configuration parameter and not a linux one...

Ahh. Thanks for the tip (I am still new to Pg).

I guess the reason Pg can't ask the running kernel how much cache mem it
has is that any such thing would be completely non-portable.

Now branching the thread:

The documentation (doc/runtime-config.html in my 7.3.2 source tree) says
the value is a number of disk pages, and that disk pages are usualy 8KB.
My filesystem has 4KB blocks; are blocks and pages the same thing in
this context, or does "page" refer to the in-memory copy of a disk
block? Are bigger blocks/pages on the filesystem used for Pg a good
idea? I would guess yes, since Pg's data files are few and large,
instead of many and small. Should I just crank my fs block size as big
as it will go, on a partition dedicated to pg_data?

Thanks.

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Avi Schwartz 2003-05-16 23:24:07 Result set return to Coldfusion MX?
Previous Message Nigel J. Andrews 2003-05-16 23:07:14 Re: - what protocol for an Internet postgres