On 8 Sep 2003 at 17:31, Andri Saar wrote:
> Note to future generations: default postgres configuration settings are very
> conservative and don't be afraid to VACUUM very often.
You should have looked at earlier default postgresql they were arcane by that
standard.
7.4 at least attempts to dete
On Monday 08 September 2003 17:04, Tom Lane wrote:
>
> It looks to me like throwing a plain VACUUM into your poller cycle
> (or possibly VACUUM ANALYZE depending on how fast the table's stats
> change) would solve your problems nicely.
>
I compled the pg_autovacuum daemon from 7.4beta sources as S
Andri Saar <[EMAIL PROTECTED]> writes:
> If this is the best you can get with postgres right now, then I'll just have
> to increase the frequency of VACUUMing, but that feels like a hackish
> solution :(
Not at all. The overhead represented by VACUUM would have to be paid
somewhere, somehow, in
On Mon, 8 Sep 2003 13:50:23 +0300, Andri Saar <[EMAIL PROTECTED]>
wrote:
>Basically I do this:
>1) select about ~700 ID's I have to poll
>2) poll them
>3) update those 700 rows in that "table" I used (~2700 rows total).
>
>And I do this cycle once per minute, so yes, I've got a zillion updates. 700
On 8 Sep 2003 at 13:50, Andri Saar wrote:
> If this is the best you can get with postgres right now, then I'll just have
> to increase the frequency of VACUUMing, but that feels like a hackish
> solution :(
Use a autovacuum daemon. There is one in postgresql contrib module. It was
introduced du
Hope that you don't find it too distracting, I decided to answer to emails in
one go.
On Saturday 06 September 2003 03:05, Tom Lane wrote:
> indexscans. If you've also got sequential-scan queries, and you're
> doing many zillion updates between vacuums, the answer is to vacuum
> more ofte
[EMAIL PROTECTED] kirjutas L, 06.09.2003 kell 00:58:
> Hi,
>
> i'm having _serious_ issues of postgres hogging up the CPU over time. A graph
> showing this can be seen at http://andri.estpak.ee/cpu0.png .
>
> The database is running on Redhat 9 (stock 2.4.20-8 kernel), on a reiserfs
> partition (
<[EMAIL PROTECTED]> writes:
> i'm having _serious_ issues of postgres hogging up the CPU over time. A graph
> showing this can be seen at http://andri.estpak.ee/cpu0.png .
You really haven't shown us anything that would explain that graph ...
repeated UPDATEs will slow down a little until you vacu
Hi,
i'm having _serious_ issues of postgres hogging up the CPU over time. A graph
showing this can be seen at http://andri.estpak.ee/cpu0.png .
The database is running on Redhat 9 (stock 2.4.20-8 kernel), on a reiserfs
partition (~8% usage - no problem there), and this problem has been with
Postg
