Re: 8.x index insert performance
От | Ron |
---|---|
Тема | Re: 8.x index insert performance |
Дата | |
Msg-id | 6.2.5.6.0.20051114104706.01dcf728@earthlink.net обсуждение исходный текст |
Ответ на | Re: 8.x index insert performance (Kelly Burkhart <kelly@tradebotsystems.com>) |
Список | pgsql-performance |
At 09:43 AM 11/14/2005, Kelly Burkhart wrote: >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. Perhaps a small schema change would help? Instead of having the order state transitions explicitly listed in the table, why not create two new tables; 1 for created orders and 1 for terminated orders. When an order is created, its ord_id goes into the CreatedOrders table. When an order is terminated, its ord_id is added to the TerminatedOrders table and then deleted from the CreatedOrders table. Downsides to this approach are some extra complexity and that you will have to make sure that system disaster recovery includes making sure that no ord_id appears in both the CreatedOrders and TerminatedOrdes tables. Upsides are that the insert problem goes away and certain kinds of accounting and inventory reports are now easier to create. Ron
В списке pgsql-performance по дате отправления: