Re: 8.x index insert performance

Поиск
Список
Период
Сортировка
От Kelly Burkhart
Тема Re: 8.x index insert performance
Дата
Msg-id 1131979410.14024.49.camel@krb06.tradebot.com
обсуждение исходный текст
Ответ на Re: 8.x index insert performance  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: 8.x index insert performance  (Ron <rjpeace@earthlink.net>)
Список pgsql-performance
On Fri, 2005-11-11 at 18:02 -0500, Tom Lane wrote:
> > There very well could be a pattern in the data which could affect
> > things, however, I'm not sure how to identify it in 100K rows out of
> > 100M.
>
> I conjecture that the problem areas represent places where the key
> sequence is significantly "more random" than it is elsewhere.  Hard
> to be more specific than that though.
>

OK, I understand the pattern now.

My two tables hold orders, and order state transitions.  Most orders
have two transitions: creation and termination.  The problem happens
when there is a significant number of orders where termination is
happening a long time after creation, causing order_transition rows with
old ord_id values to be inserted.

This is valid, so I have to figure out a way to accomodate it.

You mentioned playing with checkpointing and bgwriter earlier in this
thread.  I experimented with the bgwriter through the weekend, but I
don't have a good idea what sensible parameter changes are...

Re: checkpointing, currently my checkpoints are happening every 5
minutes (if I turn on fsync, the graph shows checkpoints dramatically).
If I increase the checkpoint_timeout, could that be beneficial?  Or
would I just have more time between larger spikes?

-K

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

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: IO Error
Следующее
От: Ron
Дата:
Сообщение: Re: 8.x index insert performance