Re: Managing EOF caching
Re: Managing EOF caching
- Subject: Re: Managing EOF caching
- From: Mike Schrag <email@hidden>
- Date: Fri, 20 Jan 2006 12:54:56 -0500
I haven't done any timings, but I find it hard to believe that this technique will effect any significant savings for most databases. As Art indicates, the only effect of reducing the number of lock columns is to correspondingly reduce the number of columns in the WHERE clause for updates and deletes.
I've always wondered this, too, so I threw together a quick test. I created two identical entities which have 3 ints, 3 booleans, 3 strings, and 3 dates as properties, but one locks all attrs and one locks none. I then inserted 10,000 of each into the db, followed by an update of the same attribute for each with the same change in value.
This was run on the latest version of FrontBase on an Intel iMac with WO 5.3:
Main.main: 10000 with all columns locked = 25753ms Main.main: 10000 with no columns locked = 7111ms
So in this test, it is 3.6x faster to not lock any columns in this example, with this database, one this hardware. Obviously db benchmarks are never this simple, so take this with a grain of salt.
ms
|
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden