On Thu, 21 Nov 2002, Egyud Csaba wrote:
> Hi,
> I do appologize you to being silent so long but I had no time to read my
> mails. Thank you all to pay attention to my silly problems.
>
> Tom Lane wrote:
> > I wonder whether this database is getting vacuumed regularly?
> > Depending on your data patterns, it might also be that you need to reindex
> every so often.
>
> You are absolutely right.
> I already vacuumed and reindexed my db, and it seems to be all right. To
> tell the truth, I couldn't try it yet on the live environment, but it was
> working on my test sever well.
>
> I read somwhere, that the number of the shared buffers should also be
> increased.
> I've browsed through the archive and found a valuable article of Bruce
> Momjian on hardware performance issues and he writes that the shared_buffers
> can be set in the postgresql.conf file.
> Simply there isn't any file whith this name on my server. I use PG v7.0.3.
> Is that possible that this conf file has been introduced in the later
> releases?
Yes, I think it showed up in 7.1.x. You should really upgrade to 7.2.3
or wait a week or two and try migrating to 7.3. They are both MUCH faster
than 7.0 was.
> There are two files in the /var/lib/pgsql/data/ directory: postmaster.opts
> and postmaster.opts.default.
> The postmaster.opts is overwritten during the postmaster's start process, so
> I lose all of my changes on it. The postmaster.opts.default file is OK after
> the start of the postmaster, but I don't know how to check weather the new
> options are working.
ps -ewx|grep postmaster
will show you that on a linux/gnu box. Not sure how to do it on other
platforms.
Normally, to make the shared buffers vary large you'll need to increase
the shmmax and shmall settings for your kernel (again, I'm speaking Linux
here) but you can usually get away with <4000 shared buffers on a stock
redhat box (4096 buffers being 32 megs, which is the max default shared
mem setting on most linux machines.) blocks, by the way, are usually 8192
bytes each, unless you've recompiled your postgresql with larger block
sizes, which isn't very commonly done.
