Who cares what the ids are? what is the % of space remaining in the int64?!
I mean seriously wtf are you taking hilo ids and showing them to users? Greg On Fri, Apr 3, 2009 at 8:37 AM, John Morales <[email protected]> wrote: > While you're right, it's quite possible to avoid reaching the upper limit on > of the data size limit, if this is what you consider good design, then good > luck to you. > > John > > On Fri, Apr 3, 2009 at 8:34 AM, John Morales <[email protected]> wrote: >> >> A more realistic example. >> >> 3 web servers 200 tables, app reseting 5 times a day >> >> 3 * 5 * 200 = 3000 high values a day >> >> the high value is multiplied by the max_lo so in just 1 year your id's >> will be in the 190 billion range.. >> >> >> While your' >> >> >> On Thu, Apr 2, 2009 at 9:04 PM, Erik Lundby <[email protected]> wrote: >>> >>> <snip> >>> >>> . those reserved ranges are lost forever, which is wasteful >>> >>> </snip> >>> >>> >>> >>> But what are you wasting? With an int64 id and that default int16 max >>> low you are talking about, wouldn’t you have something like 140 trillion >>> high values? >>> >>> So if you have 100 web servers resetting 3 times an hour, you will get >>> 7200 high values used a day. >>> >>> >>> >>> In 19 billion years you can probably just switch to int128. J >>> >>> >>> >>> Erik >>> >>> >>> >>> From: [email protected] [mailto:[email protected]] On >>> Behalf Of John Morales >>> Sent: Thursday, April 02, 2009 4:39 PM >>> To: [email protected] >>> Subject: [nhusers] Re: table hilo and application restarts/asp.net >>> >>> >>> >>> Yeah, the increment generator does not support more than 1 concurrent >>> session factory per database, which right now is all I need... And I guess I >>> should re-evaluate this decision, this is one of those times where YAGNI >>> isn't the best strategy as I might very well need to support scaling out. >>> >>> IMO, the concurrent sessionfactory support hilo has using reserved blocks >>> of id's is inefficient, contrary to what the documentation says. Once the >>> session factory is terminated. those reserved ranges are lost forever, which >>> is wasteful. With the only option is to reduce the max_lo range cap, which >>> just reduces the amount of potential waste. A more efficient generator that >>> reuses those unused ranges while allowing a clustered environment is what I >>> truly need. >>> >>> If I have some time I might help out with this. >>> >>> John >>> >>> On Thu, Apr 2, 2009 at 7:03 PM, Fabio Maulo <[email protected]> wrote: >>> >>> 2009/4/2 John Morales <[email protected]> >>> >>> >>> >>> While looking into the source I saw that the increment generator does >>> exactly what I need, it uses a cached copy of the max id for each table on >>> appdomain start and assigns id's as necessary. Without having to hit the >>> database for each insert. >>> >>> >>> >>> >>> >>> mmmm... take care with it... what happen when you have 2 webserver ? or >>> two application instance ? >>> -- >>> Fabio Maulo >>> >>> >>> >>> >>> -- >>> >>> This signature is intentionally left blank >>> >>> >>> >> >> >> >> -- >> This signature is intentionally left blank > > > > -- > This signature is intentionally left blank > > > > -- It is the mark of an educated mind to be able to entertain a thought without accepting it. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
