Re: Re: Red Hat to support PostgreSQL

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Philip Molter <philip(at)datafoundry(dot)net>
Cc: Lamar Owen <lamar(dot)owen(at)wgcr(dot)org>, Tim Barnard <tbarnard(at)povn(dot)com>, pgsql-general(at)postgresql(dot)org
Subject: Re: Re: Red Hat to support PostgreSQL
Date: 2001-06-28 03:41:23
Message-ID: 200106280341.f5S3fOu01943@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

> : In a sense threads were a solution to a process bloating problem.
> : Linux/BSD have much lighter processes and hence work better for
> : PostgreSQL. Again, this is only a guess.
> :
> : MySQL does more stuff with threads while PostgreSQL switches process
> : because each backend is a process.
>
> Does more stuff with threads? It does all stuff with threads. Your
> guess was our guess, which is why we tried shoving the thing over to a
> Linux box. Now if I only I could figure out why kernel CPU usage keeps
> going up incrementally over time (went from roughly a 5% average to a
> 16% average in two days) the more we run the system. All signs are
> pointing to postgres.
>
> VACUUM ANALYZE-ing the tables used to reduce it back down, but now, it
> doesn't appear to be as effective (might go from 16% back down to
> 13%). Anyone know what causes that, and better yet, anyone know how to
> fix it? We see similar behavior under Solaris.

My only guess is index growth. We don't reclaim disk space used by
indexes after data removal. You have to drop/recreate the index. It is
on the TODO list.

--
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

In response to

Browse pgsql-general by date

  From Date Subject
Next Message GH 2001-06-28 04:50:40 Re: installation error
Previous Message エイエムエス 2001-06-28 03:34:47 Fw: installation error