Re: VACUUM ANALYSE...

> I'd cut shared_buffers to 10000, or maybe even less. I think you get
> to the point of diminishing returns with more than a few thousand of 'em.
> IMHO it's better to give the kernel the flexibility of assigning memory
> to processes or kernel disk cache as needed. You'll cope better with
> load spikes if the kernel has memory to spare. I suspect part of the
> reason your performance is going into the ground is the kernel is being
> forced to resort to swapping (you could check this with iostat or vmstat).
ok, ill try this.
Would it make sense to lower the shmall & shmmax kernelvalues according to
the buffers memory too?

> > # VACUUM VERBOSE fullstatistic;
> > NOTICE: --Relation fullstatistic--
> > NOTICE: Pages 118815: Changed 895, Empty 0; Tup 90646: Vac 87611, Keep
167,
> > UnUsed 8777533.
>
> Here you are hurting: less than one tuple per page. This table
> desperately needs a VACUUM FULL.
How about a table dump and restore. Would it solve the problem without a
full vac?
But anyway both tables are growing. So ill let them fill it by time.
Diskspace is not (yet) spare on that machine.

Thank you
Thilo