From: | Kelly Burkhart <kelly(at)tradebotsystems(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: 8.x index insert performance |
Date: | 2005-11-14 14:43:30 |
Message-ID: | 1131979410.14024.49.camel@krb06.tradebot.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Piccarello, James (James) | 2005-11-14 15:34:42 | Postgres recovery time |
Previous Message | Marc Morin | 2005-11-14 13:25:10 | sort/limit across union all |