Re: set autovacuum=off

Поиск
Список
Период
Сортировка
От Peter van Hardenberg
Тема Re: set autovacuum=off
Дата
Msg-id CAFqOt8Hw3kzDfPdjWi9Xh2qRWBh7jBiT7yG6di4dMjeONQ0E2Q@mail.gmail.com
обсуждение исходный текст
Ответ на Re: set autovacuum=off  (Alessandro Gagliardi <alessandro@path.com>)
Список pgsql-performance
On Thu, Feb 23, 2012 at 1:07 PM, Alessandro Gagliardi
<alessandro@path.com> wrote:
>>
>> ...Apparently the last four columns don't exist in my database. As for the
>> first four, that is somewhat illuminating....
>>
>> Then you are not running a current version of PostgreSQL so the first step
>> to performance enhancement is to upgrade. (As a general rule - there are
>> occasionally specific cases where performance decreases.)
>>
> We're using 9.0.6. Peter, how do you feel about upgrading? :)
>

9.1's in beta; we're working on writing an upgrade system before
calling it GA, but it works fine. Feel free.

My hunch is still that your issue is lock contention.

> No, not average. I want to be able to do 100-200 INSERTs per second (90% of
> those would go to one of two tables, the other 10% would go to any of a
> couple dozen tables). If 1% of my INSERTs take 100 ms, then the other 99%
> must take no more than 9 ms to complete.
> ...actually, it occurs to me that since I'm now committing batches of 1000,
> a 100ms latency per commit wouldn't be bad at all! I'll have to look into
> that.... (Either that or my batching isn't working like I thought it was.)
>

We have many customers who do much more than this throughput, though
I'm not sure what level of resourcing you're current at. You might
consider experimenting with a larger system if you're having
performance problems.

Peter

В списке pgsql-performance по дате отправления:

Предыдущее
От: Lew
Дата:
Сообщение: Re: Very long deletion time on a 200 GB database
Следующее
От: Samuel Gendler
Дата:
Сообщение: Re: Very long deletion time on a 200 GB database