Re: Linux/PostgreSQL scalability issue - problem with 8 cores

> You could check this theory
> out by strace'ing some of the idle backends and seeing if their
> activity spikes are triggered by receipt of SIGUSR1 signals.

Yes, I can confirm that it's triggered by SIGUSR1 signals.

If I understand it correctly we have following choices now:

1) Use only 2 cores (out of 8 cores)

2) Lower the number of idle backends - at least force backends to do
something at different times to eliminate spikes - is "select 1" enough
to force processing the queue?

3) Is there any chance of this being fixed/improved in 8.3 or even 8.2?
It's a (performance) bug from our point of view. I realize we're first
who noticed it and it's not typical use case to have so many idle
backends. But large installation with connection pooling is something
similar and that's not that uncommon - one active backend doing DDL can
then cause unexpected spikes during otherwise quiet hours...

4) Sure we'll try to reduce the number of DDL statements (which in fact
we're not sure where exactly they are comming from) but I guess it would
only longer the time between spikes but not make them any smoother.

Any other suggestions?

Thanks,

Kuba