Re: Smoke and mirrors...

InDeep wrote: > Ian Michael Gumby wrote: >> To your point. Yes IDS will perform much better that either Oracle or >> DB2 in a VM environment. > > Let's not make sweeping statements without facts. I am glad you said this, as my first reaction was that this was typical Gumby BS. But, on the basis that maybe it's not, I would be interested in a technical discussion on this on. If the belief is that IDS does work well on virtualized platforms, and maybe better than other database servers, then my question would be "Why ?". AFAIK all the DB's have reasonably similar I/O profiles (this is changing a little/lot with our latest announcement, but is generally true), and in most VM environments, virtualized I/O becomes the issue quickly. Which is why apps etc deploy well in VM environments, and databases, not so much. So what is Informix doing any different that mitigates this ?

Mark Townsend wrote: > InDeep wrote: > >> Ian Michael Gumby wrote: >> >>> To your point. Yes IDS will perform much better that either Oracle or >>> DB2 in a VM environment. >>> >> Let's not make sweeping statements without facts. >> > > I am glad you said this, as my first reaction was that this was typical > Gumby BS. But, on the basis that maybe it's not, I would be interested > in a technical discussion on this on. If the belief is that IDS does > work well on virtualized platforms, and maybe better than other database > servers, then my question would be "Why ?". AFAIK all the DB's have > reasonably similar I/O profiles (this is changing a little/lot with our > latest announcement, but is generally true), and in most VM > environments, virtualized I/O becomes the issue quickly. Which is why > apps etc deploy well in VM environments, and databases, not so much. So > what is Informix doing any different that mitigates this ? > Checkpoints. :o) -- Cheers, Obnoxio the Clown http://obotheclown.blogspot.com

Obnoxio The Clown wrote: > Mark Townsend wrote: >> So what is Informix doing any different that mitigates >> this ? >> > > Checkpoints. :o) > Sorry, OTC, my choice of language obviously confused you: Definitions of mitigate on the Web: extenuate: lessen or to try to lessen the seriousness or extent of; "The circumstances extenuate the crime" make less severe or harsh; "mitigating circumstances"

Mark Townsend wrote: > InDeep wrote: >> Ian Michael Gumby wrote: >>> To your point. Yes IDS will perform much better that either Oracle or >>> DB2 in a VM environment. >> >> Let's not make sweeping statements without facts. > > I am glad you said this, as my first reaction was that this was typical > Gumby BS. But, on the basis that maybe it's not, I would be interested > in a technical discussion on this on. If the belief is that IDS does > work well on virtualized platforms, and maybe better than other database > servers, then my question would be "Why ?". AFAIK all the DB's have > reasonably similar I/O profiles (this is changing a little/lot with our > latest announcement, but is generally true), and in most VM > environments, virtualized I/O becomes the issue quickly. Which is why > apps etc deploy well in VM environments, and databases, not so much. So > what is Informix doing any different that mitigates this ? Wasting your time Mark. He's not done the work. He's flailing around like a politician losing traction. Product "A" is faster. Doesn't work. Bring up "data cartridges" Doesn't work. Bring up virtualization. Won't work. He'll try something else. The fact is that one of my students, last year, at the University of Washington was an SE at Informix for 15 years and we have the numbers. Which is why I am willing to call a scoundrel a scoundrel. I know he can not substantiate this nonsense. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

Mark Townsend wrote: > Obnoxio The Clown wrote: >> Mark Townsend wrote: > > >>> So what is Informix doing any different that mitigates this ? >>> >> >> Checkpoints. :o) >> > > Sorry, OTC, my choice of language obviously confused you: > > > Definitions of mitigate on the Web: > > extenuate: lessen or to try to lessen the seriousness or extent of; > "The circumstances extenuate the crime" > make less severe or harsh; "mitigating circumstances" > It was a joke. Clearly you Australians have no sense of humour. -- Cheers, Obnoxio the Clown http://obotheclown.blogspot.com

DA Morgan wrote: > Mark Townsend wrote: > >> InDeep wrote: >> >>> Ian Michael Gumby wrote: >>> >>>> To your point. Yes IDS will perform much better that either Oracle or >>>> DB2 in a VM environment. >>>> >>> Let's not make sweeping statements without facts. >>> >> I am glad you said this, as my first reaction was that this was typical >> Gumby BS. But, on the basis that maybe it's not, I would be interested >> in a technical discussion on this on. If the belief is that IDS does >> work well on virtualized platforms, and maybe better than other database >> servers, then my question would be "Why ?". AFAIK all the DB's have >> reasonably similar I/O profiles (this is changing a little/lot with our >> latest announcement, but is generally true), and in most VM >> environments, virtualized I/O becomes the issue quickly. Which is why >> apps etc deploy well in VM environments, and databases, not so much. So >> what is Informix doing any different that mitigates this ? >> > > Wasting your time Mark. He's not done the work. He's flailing around > like a politician losing traction. > > Product "A" is faster. > Doesn't work. > Bring up "data cartridges" > Doesn't work. > Bring up virtualization. > Won't work. > He'll try something else. > > The fact is that one of my students, last year, at the University > of Washington was an SE at Informix for 15 years and we have the numbers. > > Which is why I am willing to call a scoundrel a scoundrel. I know > he can not substantiate this nonsense. > Can I call a pompous blowhard, a pompous blowhard? I know I can substantiate it. -- Cheers, Obnoxio the Clown http://obotheclown.blogspot.com

> > It was a joke. Clearly you Australians have no sense of humour. > Can't have everything. After all, we have the brighest, most handsome, articulate and well hung neighbours in the world. A sense of humour would be unfair.

Mark Townsend wrote: > InDeep wrote: >> Ian Michael Gumby wrote: >>> To your point. Yes IDS will perform much better that either Oracle or >>> DB2 in a VM environment. >> >> Let's not make sweeping statements without facts. > > I am glad you said this, as my first reaction was that this was typical > Gumby BS. But, on the basis that maybe it's not, I would be interested > in a technical discussion on this on. If the belief is that IDS does > work well on virtualized platforms, and maybe better than other database > servers, then my question would be "Why ?". AFAIK all the DB's have > reasonably similar I/O profiles (this is changing a little/lot with our > latest announcement, but is generally true), and in most VM > environments, virtualized I/O becomes the issue quickly. Which is why > apps etc deploy well in VM environments, and databases, not so much. So > what is Informix doing any different that mitigates this ? Informix is certainly going to work from a minimal configuration upward, thus the original concept of "Dynamic Server", adjusting to increased load, & virtual processor allocation. ( which we need to be careful not to muddy the water with OS VMs and Informix VPs. ) What little I _do_ know about Oracles' database is that it seems to rely on a lot more processes to manage load, and seems to be more complex in how it manages resources vs Informix. ( _my_ opinion ) This is crucial to how well Oracle manages being in a VM, as well as what OTC mention, I/O. I think it's also important to understand a little more about how MVCC database(s) work vs non-MVCC. MySQL is moving in that direction, my opinion again, to compete directly with Oracle. MySQL has already said they are producing an MVCC engine, not sure if it's out yet. But back to the point, I think Informix, outside of MVCC is probably going to run faster than it would with MVCC, but I don't know enough about the latest version to know--again talking without knowing. All VMs are trying to isolate the VM at different levels, so it is natural to assume that a VM is going to be counter-productive for an Oracle instance, but again I could be completely wrong. I've had a working experience with FreeVPS, Virtuozzo, Parallels, VMWare Workstation, VMWare ESX, VirtualBox, and a little exposure to early Xen. All of these fair better or worse depending on what you want to do vs what you want to spend money on. I've seen Para-VMs perform better than VMware, but again my .02 USD. I also quoted from Burlesons' books about how to build Oracle systems, it's not about minimal configurations but maximum hardware, totally counter to how one architects softwares in VMs. See also: http://en.wikipedia.org/wiki/Virtual_machine http://en.wikipedia.org/wiki/Comparison_of_virtual_machines ( Oracles' VM is based on the Xen VM ) -- Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. Terry Pratchett

InDeep wrote: > What little I _do_ know about Oracles' database is that it seems to rely > on a lot more processes to manage load, and seems to be more complex in > how it manages resources vs Informix. ( _my_ opinion ) This is crucial to > how well Oracle manages being in a VM, as well as what OTC mention, I/O. That's my point. I don't believe it's the issue > I think it's also important to understand a little more about how MVCC > database(s) work vs non-MVCC. MySQL is moving in that direction, my > opinion again, to compete directly with Oracle. MySQL has already said > they are producing an MVCC engine, not sure if it's out yet. But back to > the point, I think Informix, outside of MVCC is probably going to run > faster than it would with MVCC, but I don't know enough about the latest > version to know--again talking without knowing. MVCC has a cost (rollback segments), but it also reduces locking. We think that avoiding the latter is better. MVCC has nothing to do with VM s however, so I am not sure I understand your point ? > All VMs are trying to isolate the VM at different levels, so it is natural > to assume that a VM is going to be counter-productive for an Oracle > instance Why ? > a > little > exposure to early Xen. All of these fair better or worse depending on what > you want to do vs what you want to spend money on. I've seen Para-VMs > perform > better than VMware, but again my .02 USD. Uh huh. And what is Oracle's VM then ? > I also quoted from Burlesons' books about how to build Oracle systems Well, there's your problem....

Mark Townsend wrote: > MVCC has a cost (rollback segments), but it also reduces locking. We > think that avoiding the latter is better. MVCC has nothing to do with VM > s however, so I am not sure I understand your point ? > The point is that it's more complex. But I'm new to the MVCC concept and still trying to get into Oracle slowly--it's not my prime focus. I only mention MVCC because anything you do that is more complex, more process-intensive, more resource-intensive, is going to be affected more dramatically in a VM. If you have a non-MVCC engine it naturally follows that it would be faster than one with MVCC. > >> All VMs are trying to isolate the VM at different levels, so it is >> natural >> to assume that a VM is going to be counter-productive for an Oracle >> instance > > Why ? > Like I said. Oracle is going to consume the box. It's not working from a 'minimalist baseline' like Informix. Oracle is working as taking everything it can like a flock of locusts, it consumes the box. Scorched earth--or in this case, scorched CPU. Not just the database, but the apps as well. On ESX the apps were literally smokin' the box, totally maxed out the VMs. The CPUs turn into spark plugs with Oracle it's amazing. >> a little >> exposure to early Xen. All of these fair better or worse depending on >> what >> you want to do vs what you want to spend money on. I've seen Para-VMs >> perform >> better than VMware, but again my .02 USD. > > Uh huh. And what is Oracle's VM then ? > A fork of Xen. Didn't you read the references? And by the way, have you ever actually worked on Oracle? Just curious. >> I also quoted from Burlesons' books about how to build Oracle systems > > Well, there's your problem.... Thanks. *<8o) -- Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. Terry Pratchett

On Oct 12, 3:35 pm, Mark Townsend <markbtowns...@sbcglobal.net> wrote: > InDeep wrote: > > Ian Michael Gumby wrote: > >> To your point. Yes IDS will perform much better that either Oracle or > >> DB2 in a VM environment. > > > Let's not make sweeping statements without facts. > > I am glad you said this, as my first reaction was that this was typical > Gumby BS. But, on the basis that maybe it's not, I would be interested > in a technical discussion on this on. If the belief is that IDS does > work well on virtualized platforms, and maybe better than other database > servers, then my question would be "Why ?". Mark, Its not. But then again, we won't know because IBM hasn't done any TPC-C or TPC- E benchmarks using IDS. If you want a technical discussion, it is not going to happen here. Those who know the internals can't talk about them. But hey! What do I know? As you said, its just BS. ;-) Maybe you can explain to me why the Oracle spatial can't apply an index to a collection based on a single table? In short, if I select from a table that has both an index on an integer column and one on a spatial column... SELECT A.obj_id FROM TAB_A A, TAB_B B WHERE A.group_id > 83000 AND SDO_FILTER. (A.foo, B.foo, 'query_type = window') = 'TRUE' ; Sorry that the syntax isn't 100%. I'm going from memory and since we're in a c.d.i forum, its not the syntax that counts but the concept.... In the query, TAB_A has a spatial index, and an index on group_id. TAB_B only has a spatial index and we're filtering A against B to get any object_ids where there is a spatial overlap (touching) with objects in TAB_A and the group_id is > some number. Oh and obviously foo is the spatial data object column. What happens is that Oracle creates a collection using the group_id first to limit the number of rows. Then when you apply the filter, Oracle doesn't use the table's underlying spatial index. I kind of find that interesting. Can you explain this behavior? But yeah, I don't know jack! :-) -G

> > What happens is that Oracle creates a collection using the group_id > first to limit the number of rows. Then when you apply the filter, > Oracle doesn't use the table's underlying spatial index. I kind of > find that interesting. Can you explain this behavior? > Not from this description. Did "the company" raise an SR for this ? If so, I can look at it

InDeep wrote: > I think it's also important to understand a little more about how MVCC > database(s) work vs non-MVCC. MySQL is moving in that direction, my > opinion again, to compete directly with Oracle. MySQL has already said > they are producing an MVCC engine, not sure if it's out yet. But back to > the point, I think Informix, outside of MVCC is probably going to run > faster than it would with MVCC, but I don't know enough about the latest > version to know--again talking without knowing. One might point out that PostgreSQL, SQL Server 2005 and SQL Server 2008 have implementations of MVCC too. How soon DB2 Serge? But heck why go with the overhead of MVCC when you can have dirty reads. You can wash your car faster too if you don't mind leaving it a bit dirty. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

> I also quoted from Burlesons' books about how to build Oracle systems To be as gentle as possible in the face of overt provocation: http://asktom.oracle.com/pls/ask/download_file?p_file=3067171813508366601 I'm quite sure you know who Tom Kyte is. From Jonathan Lewis http://www.jlcomp.demon.co.uk/untested.html You can pretty much google any internationally recognized Oracle professional and the name "Burleson" and find more of the same. As Mark said: "Well, there's your problem.... " -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

InDeep wrote: > The point is that it's more complex. But I'm new to the MVCC concept and > still trying to get into Oracle slowly--it's not my prime focus. I only > mention MVCC because anything you do that is more complex, more > process-intensive, > more resource-intensive, is going to be affected more dramatically in a > VM. If > you have a non-MVCC engine it naturally follows that it would be faster > than > one with MVCC. Actually that is not the case. Consider the following as a very simplistic example. Suppose your requirement is to query a 100TB table for accurate bank balances as of midnight. That's it. Exactly midnight and you must have an accurate balance on all accounts and each account has tens of thousands of records equally distributed throughout the 100TB table. So we are talking about a full table scan occurring at a fixed point in time. And yes there are ATM machines and batch processes and other activities taking place on the system at the same time you are running your report. Do you think you are going to have lower overhead without MVCC? Do you think it is going to be faster without MVCC? -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

> Suppose your requirement is to query a 100TB table for accurate bank > balances as of midnight. That's it. Exactly midnight and you must > have an accurate balance on all accounts and each account has tens > of thousands of records equally distributed throughout the 100TB > table. So we are talking about a full table scan occurring at a > fixed point in time. And yes there are ATM machines and batch > processes and other activities taking place on the system at the > same time you are running your report. > > Do you think you are going to have lower overhead without MVCC? > Do you think it is going to be faster without MVCC? Ah, now that we have reached a technical discussion (and it' sproven that my absense in no way shortens these threads... ) time to jump in: 1. MvCC applies to the entire database. In common usages these "point of time queries" are not required on teh entire database, but merely on a very distinct set of tables. 2. In you example of bank transaction I take it for granted that a bank is able to tell me when the transaction happened (and wen it will count!). Ironically this time is NOT the database transaction time, it is the time at which the BUSINESS transaction was submitted (or concluded depending on ones taste). It is NOT the DBMS business to serve as a clock for business transactions. Having said that there will be an official timestamp for such a business transaction stored in the row or some side table. 3. IDS supports "readers don't block writers and writers don't block readers". This is not done through roll back segments. The important art here is that a writer doesn't have to pay ever for the improved concurrence and a reader only pays if there is an issue with that row (is it true that rollback segments work on a page level, that is the reader has to re-constitute any modified page first even if the row was never changed?. 4. MvCC to the best of my knowledge implies double the I/O as compared to IDS's implementation because the rollback segments need to be maintained and logged. 5. Let's keep concurrency (reader don't block writers, ...) and isolation (Snapshot) nicely separated. I find it in general embarassing whenever so-called DBMS experts (of any creed!) muddle them. To conclude Mark points out that IDS and Oracle have the same I/O characteristics. That is simply not correct due to MvCCs 2x multiplier. Further more in a VM system ultra high high concurrency is presumably not the first requirement that comes to mind I dare say and IDS Cheetah does not have an issue with concurrency to begin with. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

In article <6lgq6fFbs7krU1@mid.individual.net>, Serge Rielau says... >5. Let's keep concurrency (reader don't block writers, ...) and >isolation (Snapshot) nicely separated. I find it in general embarassing >whenever so-called DBMS experts (of any creed!) muddle them. Jeez. Daniel is not an expert on anything except pimping. The fact that he is woefully unaware of Informix's deadlock detection capability (which informix has since OL 4.0 in 1990) tells that except for pimping for his whOre, he has no other skill.

On Oct 13, 6:36 am, Serge Rielau <srie...@ca.ibm.com> wrote: > To conclude Mark points out that IDS and Oracle have the same I/O > characteristics. That is simply not correct due to MvCCs 2x multiplier. > Further more in a VM system ultra high high concurrency is presumably > not the first requirement that comes to mind I dare say and IDS Cheetah > does not have an issue with concurrency to begin with. > Ah there's a little more to it than that. But that's getting in to a different technical discussion... It gets in to what you mean by I/ O. ;-) (And I'm not talking disk.) Unfortunately, a lot of this information is only on power points and the hardware won't be out for a couple of months. If you can afford it. Sun Rock anyone? Or the cell chips by IBM and friends? The real issue is that this is all BS until IBM releases some benchmarks on IDS in either TPC-C and TPC-E categories. One also has to ask... Can IDS do a TPC-E using datablades like RTL and Time Series? ;-) -G

On Oct 13, 9:24 am, dcrunch...@aim.com wrote: > In article <6lgq6fFbs7k...@mid.individual.net>, Serge Rielau says... perts (of any creed!) muddle them. > > Jeez. Daniel is not an expert on anything except pimping. > The fact that he is woefully unaware of Informix's deadlock > detection capability (which informix has since OL 4.0 in 1990) > tells that except for pimping for his whOre, he has no other > skill. 4.0 was Turbo not Online. And it had a lot of warts. It was the first release to go raw though. 5.x was a much needed improvement. There are still some shops using it today until their hardware goes bad. ;-) -G

> 4. MvCC to the best of my knowledge implies double the I/O as compared > to IDS's implementation because the rollback segments need to be > maintained and logged. Hmm - Maintaining undo shouldn't imply twice the I/O (unless something weird is going on). Twice the I/O of what - block writing, checkpointing ?

In article <dc006a90-2377-4eac-a7b7-e7ef041e5c9d@p49g2000hsd.googlegroups.com>, Ian Michael Gumby says... >4.0 was Turbo not Online. >And it had a lot of warts. It was the first release to go raw though. > >5.x was a much needed improvement. There are still some shops using it >today until their hardware goes bad. ;-) wrong. informix turbo was 3.0. (released 1987). They named it turbo because until then the only engine informix had was SE. 4.0 was named on-line and one of the reason why it was called online was that it supported online backups.

On Oct 13, 10:56 am, dcrunch...@aim.com wrote: > In article <dc006a90-2377-4eac-a7b7-e7ef041e5...@p49g2000hsd.googlegroups.com>, > Ian Michael Gumby says... > > >4.0 was Turbo not Online. > >And it had a lot of warts. It was the first release to go raw though. > > >5.x was a much needed improvement. There are still some shops using it > >today until their hardware goes bad. ;-) > > wrong. > > informix turbo was 3.0. (released 1987). > They named it turbo because until then the only > engine informix had was SE. > > 4.0 was named on-line and one of the reason why it was called > online was that it supported online backups. I'd go back and check. Turbo was 4.0 OL was 5.0 And no Turbo wasn't released until '89 as memory serves me. I still have the launch coffe mug along with some WINGZ stuff. You sure you're not thinking of SE? In '89 I could have sworn SE was around 3.3 release, but that was a long time ago.

Mark Townsend wrote: > >> 4. MvCC to the best of my knowledge implies double the I/O as compared >> to IDS's implementation because the rollback segments need to be >> maintained and logged. > > Hmm - Maintaining undo shouldn't imply twice the I/O (unless something > weird is going on). Twice the I/O of what - block writing, checkpointing ? Every update to a row by definition has 2 I/O: Log + data. In MvCC the old version of the row needs to be copied into the undo and to the best of my knowledge that itself is a logged operation (so I am told). Grand total 4 I/O. Of course logical I/O does not imply that each change is _individually_ scribbled onto the hard drive. If I got that wrong I'll gladly be educated. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab

DCrusher is right Gumby. In 1988 the non-shared memory Informix database which was later renamed Standard Engine was joined by the shared memory version called Turbo which came out of a project requested by AT&T (I actually used that first Turbo shared memory engine on AT&T 3B2's for a project at AT&T Long Distance for billing systems in 1990). Both were versioned as v3.30. A year later online archives were added to the Turbo engine and v4.00 was renamed Informix Online. Art On Mon, Oct 13, 2008 at 12:10 PM, Ian Michael Gumby <im_gumby@hotmail.com>wrote: > On Oct 13, 10:56 am, dcrunch...@aim.com wrote: > > In article < > dc006a90-2377-4eac-a7b7-e7ef041e5...@p49g2000hsd.googlegroups.com>, > > Ian Michael Gumby says... > > > > >4.0 was Turbo not Online. > > >And it had a lot of warts. It was the first release to go raw though. > > > > >5.x was a much needed improvement. There are still some shops using it > > >today until their hardware goes bad. ;-) > > > > wrong. > > > > informix turbo was 3.0. (released 1987). > > They named it turbo because until then the only > > engine informix had was SE. > > > > 4.0 was named on-line and one of the reason why it was called > > online was that it supported online backups. > I'd go back and check. > Turbo was 4.0 > OL was 5.0 > > And no Turbo wasn't released until '89 as memory serves me. > I still have the launch coffe mug along with some WINGZ stuff. > > You sure you're not thinking of SE? In '89 I could have sworn SE was > around 3.3 release, but that was a long time ago. > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Art S. Kagel Oninit (www.oninit.com) IIUG Board of Directors (art@iiug.org) Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Oninit, the IIUG, nor any other organization with which I am associated either explicitly or implicitly. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves.

On Oct 13, 11:43 am, "Art Kagel" <art.ka...@gmail.com> wrote: > DCrusher is right Gumby.  In 1988 the non-shared memory Informix database > which was later renamed Standard Engine was joined by the shared memory > version called Turbo which came out of a project requested by AT&T (I > actually used that first Turbo shared memory engine on AT&T 3B2's for a > project at AT&T Long Distance for billing systems in 1990).  Both were > versioned as v3.30.  A year later online archives were added to the Turbo > engine and v4.00 was renamed Informix Online. > > Art > > On Mon, Oct 13, 2008 at 12:10 PM, Ian Michael Gumby <im_gu...@hotmail.com>wrote: Ok. Not something to fight over, but I'm pretty sure that Turbo was 4.0. I don't recall a Turbo 3.3. I'm not saying I'm not wrong, just that I don't remember it as such. I do have the Turbo launch mug from '89 which could have been the "Online mug". Any other old timers?

I've worked with Informix 4.0... I would say that it was "turbo", and I'm sure 5.0 was "Online". It had tbinit and tb* commands... But I wouldn't bet anything on this... What I would bet is that we all know who can be sure about it :) I even bet is has all the manuals :) Maybe he replies... Oh... I'm not an "old timer"! :) On Mon, Oct 13, 2008 at 6:04 PM, Ian Michael Gumby <im_gumby@hotmail.com> wrote: > On Oct 13, 11:43 am, "Art Kagel" <art.ka...@gmail.com> wrote: >> DCrusher is right Gumby. In 1988 the non-shared memory Informix database >> which was later renamed Standard Engine was joined by the shared memory >> version called Turbo which came out of a project requested by AT&T (I >> actually used that first Turbo shared memory engine on AT&T 3B2's for a >> project at AT&T Long Distance for billing systems in 1990). Both were >> versioned as v3.30. A year later online archives were added to the Turbo >> engine and v4.00 was renamed Informix Online. >> >> Art >> >> On Mon, Oct 13, 2008 at 12:10 PM, Ian Michael Gumby <im_gu...@hotmail.com>wrote: > > Ok. > Not something to fight over, but I'm pretty sure that Turbo was 4.0. > > I don't recall a Turbo 3.3. I'm not saying I'm not wrong, just that I > don't remember it as such. > I do have the Turbo launch mug from '89 which could have been the > "Online mug". > > Any other old timers? > > _______________________________________________ > Informix-list mailing list > Informix-list@iiug.org > http://www.iiug.org/mailman/listinfo/informix-list > -- Fernando Nunes Portugal http://informix-technology.blogspot.com My email works... but I don't check it frequently...

Online 4.1 in september/october 1992, so brand new that nobody knew how to mix 4GL on one machine, Online on the second machine with Star and Net. Turbo was (don´t beat me...) a (new) marketing name for the classical SE Engine. Joerg Volz -----Ursprüngliche Nachricht----- Von: informix-list-bounces@iiug.org [mailto:informix-list-bounces@iiug.org] Im Auftrag von Ian Michael Gumby Gesendet: Montag, 13. Oktober 2008 19:05 An: informix-list@iiug.org Betreff: Re: Smoke and mirrors... On Oct 13, 11:43 am, "Art Kagel" <art.ka...@gmail.com> wrote: > DCrusher is right Gumby.  In 1988 the non-shared memory Informix > database which was later renamed Standard Engine was joined by the > shared memory version called Turbo which came out of a project > requested by AT&T (I actually used that first Turbo shared memory > engine on AT&T 3B2's for a project at AT&T Long Distance for billing > systems in 1990).  Both were versioned as v3.30.  A year later online > archives were added to the Turbo engine and v4.00 was renamed Informix Online. > > Art > > On Mon, Oct 13, 2008 at 12:10 PM, Ian Michael Gumby <im_gu...@hotmail.com>wrote: Ok. Not something to fight over, but I'm pretty sure that Turbo was 4.0. I don't recall a Turbo 3.3. I'm not saying I'm not wrong, just that I don't remember it as such. I do have the Turbo launch mug from '89 which could have been the "Online mug". Any other old timers? _______________________________________________ Informix-list mailing list Informix-list@iiug.org http://www.iiug.org/mailman/listinfo/informix-list IT Handel und Beratung Jörg Volz Bernhard-Früh-Str. 7 77855 Achern GERMANY Tel: 07841-681651 Fax: 07841-681654 Mobil: 0170-2989757 Ust-ID: DE201383541 http://www.it-volz.de

Serge Rielau wrote: > Mark Townsend wrote: >> >>> 4. MvCC to the best of my knowledge implies double the I/O as >>> compared to IDS's implementation because the rollback segments need >>> to be maintained and logged. >> >> Hmm - Maintaining undo shouldn't imply twice the I/O (unless something >> weird is going on). Twice the I/O of what - block writing, >> checkpointing ? > Every update to a row by definition has 2 I/O: Log + data. There is no recoverable system that doesn't write both data and logs. Surely you are not advocating non-recoverable production databases. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)

DA Morgan wrote: > Serge Rielau wrote: >> Mark Townsend wrote: >>> >>>> 4. MvCC to the best of my knowledge implies double the I/O as >>>> compared to IDS's implementation because the rollback segments need >>>> to be maintained and logged. >>> >>> Hmm - Maintaining undo shouldn't imply twice the I/O (unless >>> something weird is going on). Twice the I/O of what - block writing, >>> checkpointing ? >> Every update to a row by definition has 2 I/O: Log + data. > > There is no recoverable system that doesn't write both data and logs. > Surely you are not advocating non-recoverable production databases. Did you read the SECOND sentence where 2 I/O turn into 4 I/O? Comment on that if you want to contribute :-) Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab