Re: Smoke and mirrors...
Not a support question but an argument about architecture: Serge Rielau (DB2) claimed Oracle's MVCC/undo design doubles write I/O (undo plus log plus data) compared with Informix IDS, while Daniel Morgan countered that undo is usually only a buffer write, so at most three I/Os occur, and that I/O size matters as much as I/O count. Mark Townsend argued every engine pays some I/O tax (undo vs checkpointing) and the comparison is apples-to-oranges; he also raised VM support policies. Others objected to using DB2 TPC results as proof about IDS and asked for actual IDS/Oracle TPC-C benchmarks, which never appeared. The thread drifted into Informix/IBM history and personal insults, with no resolution.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Serge Rielau wrote: > 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 One logical (potentially physical) I/O to undo. Commit. One physical write to the log file. One physical write to the data file. Oracle does not write uncommitted transactions to the log file. But surely you knew that already. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
DA Morgan wrote: > One logical (potentially physical) I/O to undo. > Commit. > One physical write to the log file. ... which includes logging of the UNDO > One physical write to the data file. I rest my case. Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab
Serge Rielau wrote: > DA Morgan wrote: >> One logical (potentially physical) I/O to undo. >> Commit. >> One physical write to the log file. > ... which includes logging of the UNDO >> One physical write to the data file. > > I rest my case. > Serge Only if 1+2=4 in Toronto. And only if you believe all writes contain the same number of bytes. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
DA Morgan wrote: > Serge Rielau wrote: >> DA Morgan wrote: >>> One logical (potentially physical) I/O to undo. >>> Commit. >>> One physical write to the log file. >> ... which includes logging of the UNDO >>> One physical write to the data file. >> >> I rest my case. >> Serge > > Only if 1+2=4 in Toronto. And only if you believe all writes > contain the same number of bytes. Let's cut to the chase: even 3 is bigger than 2. So I do not need to convince you that Oracle does 4 I/O whereas IDS does 2 I/O. It is sufficient that we agree that at least 3 I/Os are being done. W.r.t. number of bytes, I do not have the IDS numbers, but if you check out TPC and you look past the marketing numbers you will find that Oracle benchmarks tend to chew through a lot more log than a non MvCC DBMS such as DB2. The proof is out there. :-) Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab
> From: srielau@ca.ibm.com> Let's cut to the chase: even 3 is bigger than 2.> So I do not need to convince you that Oracle does 4 I/O whereas IDS does > 2 I/O. It is sufficient that we agree that at least 3 I/Os are being done.> W.r.t. number of bytes, I do not have the IDS numbers, but if you check > out TPC and you look past the marketing numbers you will find that > Oracle benchmarks tend to chew through a lot more log than a non MvCC > DBMS such as DB2. The proof is out there. :-) No Serge, that's not proof. The discussion started when Mark questioned my statement about IDS performing much better that Oracle in a VM type of environment. You can't use a TPC-C benchmark of DB2 to prove anything about IDS. That's about as bad as Oracle's smoke and mirrors marketing that they were famous for in the 90's. ;-) I think we all agree that we will need to see something of a TPC-C or TPC-E benchmarks to show this to be true. Oh snap. Besides IDS, how old is the last Oracle benchmark? Maybe this is why they don't do benchmarks anymore? :-P -G _________________________________________________________________ Want to do more with Windows Live? Learn “10 hidden secrets” from Jamie. http://windowslive.com/connect/post/jamiethomson.spaces.live.com-Blog-cns!550F681DAD532637!5295.entry?ocid=TXT_TAGLM_WL_domore_092008
Ian Michael Gumby wrote: > > > > From: srielau@ca.ibm.com > > > Let's cut to the chase: even 3 is bigger than 2. > > So I do not need to convince you that Oracle does 4 I/O whereas IDS does > > 2 I/O. It is sufficient that we agree that at least 3 I/Os are being > done. > > W.r.t. number of bytes, I do not have the IDS numbers, but if you check > > out TPC and you look past the marketing numbers you will find that > > Oracle benchmarks tend to chew through a lot more log than a non MvCC > > DBMS such as DB2. The proof is out there. :-) > > No Serge, that's not proof. > The discussion started when Mark questioned my statement about IDS > performing much better that Oracle in a VM type of environment. > You can't use a TPC-C benchmark of DB2 to prove anything about IDS. > That's about as bad as Oracle's smoke and mirrors marketing that they > were famous for in the 90's. ;-) > > I think we all agree that we will need to see something of a TPC-C or > TPC-E benchmarks to show this to be true. Michael with friends like you who needs enemies? That's what I get for trying to help... The discussion has been about I/O characteristics which Mark claimed to be similar for. I have been spending the last few post arguing that Oracle does more I/O than other DBMS and TPC is very well capable of showing these. It requires sticking ones nose into the full disclosure though. Anyway enough posting on that topic. Cheers Serge -- Serge Rielau DB2 Solutions Development IBM Toronto Lab
Actually Serge your comments are welcome. I was treading into an unknown area with MVCC, and I appreciate your comments, they helped underscore my original point that Oracle should be compared with other MVCC engines in a VM in order to be fair to Oracle. MVCC is not a bad thing, I welcome this feature on IDS, as it cracks one of the main selling points about Oracle. AGAIN, MVCC IS A GOOD THING as far as I'm concerned. Mark had questioned why Oracle might have issues that IDS doesn't and I think this has been a great discussion. I learned a lot from you guys! 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 Serge Rielau wrote: > Ian Michael Gumby wrote: >> >> >> > From: srielau@ca.ibm.com >> >> > Let's cut to the chase: even 3 is bigger than 2. >> > So I do not need to convince you that Oracle does 4 I/O whereas IDS >> does >> > 2 I/O. It is sufficient that we agree that at least 3 I/Os are >> being done. >> > W.r.t. number of bytes, I do not have the IDS numbers, but if you >> check >> > out TPC and you look past the marketing numbers you will find that >> > Oracle benchmarks tend to chew through a lot more log than a non MvCC >> > DBMS such as DB2. The proof is out there. :-) >> >> No Serge, that's not proof. >> The discussion started when Mark questioned my statement about IDS >> performing much better that Oracle in a VM type of environment. >> You can't use a TPC-C benchmark of DB2 to prove anything about IDS. >> That's about as bad as Oracle's smoke and mirrors marketing that they >> were famous for in the 90's. ;-) >> >> I think we all agree that we will need to see something of a TPC-C or >> TPC-E benchmarks to show this to be true. > Michael with friends like you who needs enemies? That's what I get for > trying to help... > The discussion has been about I/O characteristics which Mark claimed to > be similar for. I have been spending the last few post arguing that > Oracle does more I/O than other DBMS and TPC is very well capable of > showing these. It requires sticking ones nose into the full disclosure > though. > > Anyway enough posting on that topic. > > Cheers > Serge
InDeep wrote: > Actually Serge your comments are welcome. I was treading into an unknown > area with MVCC, and I appreciate your comments, they helped underscore my > original point that Oracle should be compared with other MVCC engines in a > VM in order to be fair to Oracle. MVCC is not a bad thing, I welcome this > feature on IDS, as it cracks one of the main selling points about Oracle. > AGAIN, MVCC IS A GOOD THING as far as I'm concerned. Mark had questioned > why Oracle might have issues that IDS doesn't and I think this has been a > great discussion. I learned a lot from you guys! > > THANKS! > I still don't believe the I/O differences are as extreme as Serge makes out - the algorithms in Oracle are highly optimized (after 20 years). All engines have their level of I/O tax that you have to pay - with Oracle, it's undo. With others, it's checkpointing, or other areas. It's always going to be an Apples to Oranges comparison, and difficult to measure, so sort of a moot point. The other issues with VMs is support. Database software vendors often hold support contracts in turn with the OS vendors they support. These provide for a level of escalation if a problem is found in the OS (and that happens quite regularly). Putting a third party VM layer between the database and the OS makes that process a little more difficult - and you will quite clearly see this reflected in Oracle's stance (you are supported, however any problems may need to be reproduced on the base OS system to get a fix). That's also why VMs where we have the source code are interesting as well. I have looked at IBM's pricing for DB2 on virtualized environments, but never really looked at support policies. Does a third party VM complicate IDS support in any way (or, of more interest to me, DB2) ?
On Oct 14, 9:25 am, Serge Rielau <srie...@ca.ibm.com> wrote: > Michael with friends like you who needs enemies? That's what I get for > trying to help... > The discussion has been about I/O characteristics which Mark claimed to > be similar for. I have been spending the last few post arguing that > Oracle does more I/O than other DBMS and TPC is very well capable of > showing these. It requires sticking ones nose into the full disclosure > though. > Sorry Serge but I don't think its really fair to be discussing IDS and in an IDS forum to say ... " ... well if you look at a DB2 benchmark, I've just proven my point...". No offense but DB2 isn't IDS and while you're talking about the I/O overhead, the only real way to honest answer the question would be for both a recent Oracle and recent IDS benchmark using TPC-C. Of course you could then compare it to comparable DB2 benchmarks. Ooops! We wouldn't want that now would we? :-) Naw, c'mon mate, don't get your panties in a bind. When I made my statement I ignored I/O because well, you can kind of cheat these days by going to an SSD that's right on the PCIe bus and skip the who SSD as a Disk model. (There's an article in el Reg on this.) True there's the additional overhead of the I/O, even to an SSD, but you're going to have to really look closely at the results. But there's more to IDS that gives it an advantage over Oracle when it comes to VMs. ;-) And I digress. I do appreciate your comments Serge, but when you point to a DB2 benchmark, now that's a cop out. Besides there's really no recent Oracle benchmark to compare it to... right? -G
DA Morgan said: > Serge Rielau wrote: >> Da Moron wrote: >>> One logical (potentially physical) I/O to undo. >>> Commit. >>> One physical write to the log file. >> ... which includes logging of the UNDO >>> One physical write to the data file. >> >> I rest my case. >> Serge > > Only if 1+2=4 in Toronto. And only if you believe all writes > contain the same number of bytes. Oh. So if a write has fewer bytes, it's less of a write? -- Bye now, Obnoxio http://obotheclown.blogspot.com/
Serge Rielau wrote: > DA Morgan wrote: >> Serge Rielau wrote: >>> DA Morgan wrote: >>>> One logical (potentially physical) I/O to undo. >>>> Commit. >>>> One physical write to the log file. >>> ... which includes logging of the UNDO >>>> One physical write to the data file. >>> >>> I rest my case. >>> Serge >> >> Only if 1+2=4 in Toronto. And only if you believe all writes >> contain the same number of bytes. > Let's cut to the chase: even 3 is bigger than 2. > So I do not need to convince you that Oracle does 4 I/O whereas IDS does > 2 I/O. Actually you do because that is not what I posted and that is not what happens most of the time. Look, again, at what I posted: above. One logical (potentially physical) I/O to undo. This is a write to a buffer that likely will never be flushed to disk. But in a worst case scenario pio=1 Commit pio is still 1 One physical write to the log file. pio = 2 One physical write to the data file. pio = 3 Now how did you come up with 4? Or, as I suggested, perhaps in Toronto 1+2=4. <g> -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
Ian Michael Gumby wrote: > Sorry Serge but I don't think its really fair to be discussing IDS and > in an IDS forum to say ... " ... well if you look at a DB2 benchmark, > I've just proven my point...". > No offense but DB2 isn't IDS .... Given Serge works with DB2, not Informix, his post is understandable. What is not understandable is why IBM doesn't have someone in Serge's position, working with Informix, willing to stand up. Is it because they don't exist? Don't care enough about the product? Or are afraid that saying something will cost them their job? -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
DA Morgan said: > Ian Michael Gumby wrote: > >> Sorry Serge but I don't think its really fair to be discussing IDS and >> in an IDS forum to say ... " ... well if you look at a DB2 benchmark, >> I've just proven my point...". >> No offense but DB2 isn't IDS .... > > Given Serge works with DB2, not Informix, his post is understandable. > What is not understandable is why IBM doesn't have someone in Serge's > position, working with Informix, willing to stand up. > > Is it because they don't exist? > Don't care enough about the product? > Or are afraid that saying something will cost them their job? Maybe they just have better things to do with their days than respond to shills and trolls. -- Bye now, Obnoxio http://obotheclown.blogspot.com/
Obnoxio The Clown wrote: > DA Morgan said: >> Serge Rielau wrote: >>> Da Moron wrote: >>>> One logical (potentially physical) I/O to undo. >>>> Commit. >>>> One physical write to the log file. >>> ... which includes logging of the UNDO >>>> One physical write to the data file. >>> I rest my case. >>> Serge >> Only if 1+2=4 in Toronto. And only if you believe all writes >> contain the same number of bytes. > > Oh. So if a write has fewer bytes, it's less of a write? Only if you think that writing 80 bytes is more overhead than writing 8 bytes. Perhaps you still think size doesn't matter. <g> -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
DA Morgan said: > Obnoxio The Clown wrote: >> DA Morgan said: >>> Serge Rielau wrote: >>>> Da Moron wrote: >>>>> One logical (potentially physical) I/O to undo. >>>>> Commit. >>>>> One physical write to the log file. >>>> ... which includes logging of the UNDO >>>>> One physical write to the data file. >>>> I rest my case. >>>> Serge >>> Only if 1+2=4 in Toronto. And only if you believe all writes >>> contain the same number of bytes. >> >> Oh. So if a write has fewer bytes, it's less of a write? > > Only if you think that writing 80 bytes is more overhead than > writing 8 bytes. > > Perhaps you still think size doesn't matter. <g> Never mind the length, feel the girth. However, if you're talking about IOs, a 8-byte IO is still an IO, just as much as an 80-byte IO is an IO. We weren't discussing the number of bytes, just the number of IOs. Reading is everything. -- Bye now, Obnoxio http://obotheclown.blogspot.com/
Obnoxio The Clown wrote: > DA Morgan said: >> Ian Michael Gumby wrote: >> >>> Sorry Serge but I don't think its really fair to be discussing IDS and >>> in an IDS forum to say ... " ... well if you look at a DB2 benchmark, >>> I've just proven my point...". >>> No offense but DB2 isn't IDS .... >> Given Serge works with DB2, not Informix, his post is understandable. >> What is not understandable is why IBM doesn't have someone in Serge's >> position, working with Informix, willing to stand up. >> >> Is it because they don't exist? >> Don't care enough about the product? >> Or are afraid that saying something will cost them their job? > > Maybe they just have better things to do with their days than respond to > shills and trolls. > That's what we have YOU for. *<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
> Date: Wed, 15 Oct 2008 23:39:45 -0700 > From: damorgan@psoug.org > Subject: Re: Smoke and mirrors... > To: informix-list@iiug.org > > Ian Michael Gumby wrote: > > > Sorry Serge but I don't think its really fair to be discussing IDS and > > in an IDS forum to say ... " ... well if you look at a DB2 benchmark, > > I've just proven my point...". > > No offense but DB2 isn't IDS .... > > Given Serge works with DB2, not Informix, his post is understandable. > What is not understandable is why IBM doesn't have someone in Serge's > position, working with Informix, willing to stand up. > > Is it because they don't exist? > Don't care enough about the product? > Or are afraid that saying something will cost them their job? No Daniel, Serge works on DB2 and because of the bloated staff in Markham, Serge has the free time to play. Lenexa is a lean team and they focus on getting work done. That's why its a much better engine than anyone at Oracle or in IBM would care to admit publicly. Which is why we need the benchmark. IDS is the greener engine of the three, hands down. I'm sure Oracle would gain some carbon credits if you suddenly stopped spouting all your hot air about Oracle. ;-) -G _________________________________________________________________ Want to read Hotmail messages in Outlook? The Wordsmiths show you how. http://windowslive.com/connect/post/wedowindowslive.spaces.live.com-Blog-cns!20EE04FBC541789!167.entry?ocid=TXT_TAGLM_WL_hotmail_092008
In article <mailman.148.1224164571.874.informix-list@iiug.org>, Ian Michael Gumby says... > That's why its a much better engine than anyone at Oracle > or in IBM would care to admit publicly. and what informix pimps would not like to admit that without IBM's bailout in 2001 by now the company would have met the same fate like Enron, Lehman, Worldcom. When Informix as an independent company could not do jackshit, why do u blame IBM.
DA Morgan wrote: > Obnoxio The Clown wrote: >> DA Morgan said: >>> Serge Rielau wrote: >>>> Da Moron wrote: >>>>> One logical (potentially physical) I/O to undo. >>>>> Commit. >>>>> One physical write to the log file. >>>> ... which includes logging of the UNDO >>>>> One physical write to the data file. >>>> I rest my case. >>>> Serge >>> Only if 1+2=4 in Toronto. And only if you believe all writes >>> contain the same number of bytes. >> >> Oh. So if a write has fewer bytes, it's less of a write? > > Only if you think that writing 80 bytes is more overhead than > writing 8 bytes. > > Perhaps you still think size doesn't matter. <g> Last time I checked with the hardware folks, 80 vrs 8 really didn't matter because of read before writes.
> From: dcruncher4@aim.com > Subject: Re: RE: Smoke and mirrors... > Date: Thu, 16 Oct 2008 07:25:16 -0700 > To: informix-list@iiug.org > > In article <mailman.148.1224164571.874.informix-list@iiug.org>, Ian Michael > Gumby says... > > > That's why its a much better engine than anyone at Oracle > > or in IBM would care to admit publicly. > > and what informix pimps would not like to admit that without IBM's bailout in > 2001 > by now the company would have met the same fate like Enron, Lehman, Worldcom. > When Informix as an independent company could not do jackshit, why do u blame > IBM. Do you really want to go down that path? PG sold the database assets to IBM for a billion. Far cheaper than it was worth. The question you had to ask is why did he split up Informix from Ascential and sell it off piecemeal. That's not what PG normally does. Oh there's much more to this and if you think about it... you'd want to puke. If it was known that he would sell off Informix for a billion, there would have been more bidders. At the time, how much sales revenue did IDS generate, even with incompetents like Finocciao and Dexmier? Sorry IBM didn't do anyone a favor. Especially since Janet tried to kill it. -G _________________________________________________________________ You live life beyond your PC. So now Windows goes beyond your PC. http://clk.atdmt.com/MRT/go/115298556/direct/01/
In article <mailman.154.1224176505.874.informix-list@iiug.org>, Ian Michael Gumby says... hey asshole, you can spend your time better by jerking off, but since you asked for it... >Do you really want to go down that path? > >PG sold the database assets to IBM for a billion. Far cheaper than it was w= >orth. > >The question you had to ask is why did he split up Informix from Ascential = >and sell it off piecemeal. That's not what PG normally does. why was the situation created when informix had to get a new buyer. what the fuck were morons like you doing from 1987 to 2001 at Informix Corp. >Sorry IBM didn't do anyone a favor. Especially since Janet tried to kill it= without IBM there would have been no informix today. at least be happy for that. no wait. without informix you would not have been posting here which means your day job is gone,.
Sigh. Look, if you want to have a serious discussion about Informix prior to the purchase of its assets by IBM, I'd be glad to fill you in on a couple of things offline. IBM did not do Informix any favors. Believe me. If you ran the numbers, a billion dollars was on the cheap side. At the time, you could have taken the database part of Ass-n-tail private and it and under proper management, it would have come out ahead. Tech companies with less revenue stream have been sold for far more. Seems that someone has hit the bottle early. -G > From: dcruncher4@aim.com> Subject: Re: RE: Smoke and mirrors...> Date: Thu, 16 Oct 2008 11:30:12 -0700> To: informix-list@iiug.org> > In article <mailman.154.1224176505.874.informix-list@iiug.org>, Ian Michael> Gumby says...> > hey asshole, you can spend your time better by jerking off,> but since you asked for it...> > >Do you really want to go down that path?> >> >PG sold the database assets to IBM for a billion. Far cheaper than it was w=> >orth.> >> >The question you had to ask is why did he split up Informix from Ascential => >and sell it off piecemeal. That's not what PG normally does.> > why was the situation created when informix had to get a new buyer.> what the fuck were morons like you doing from 1987 to 2001 at> Informix Corp.> > >Sorry IBM didn't do anyone a favor. Especially since Janet tried to kill it=> > without IBM there would have been no informix today. at least be happy> for that. no wait. without informix you would not have been posting here> which means your day job is gone,.> > _______________________________________________> Informix-list mailing list> Informix-list@iiug.org> http://www.iiug.org/mailman/listinfo/informix-list _________________________________________________________________ Stay organized with simple drag and drop from Windows Live Hotmail. http://windowslive.com/Explore/hotmail?ocid=TXT_TAGLM_WL_hotmail_102008
Obnoxio The Clown wrote: > DA Morgan said: >> Obnoxio The Clown wrote: >>> DA Morgan said: >>>> Serge Rielau wrote: >>>>> Da Moron wrote: >>>>>> One logical (potentially physical) I/O to undo. >>>>>> Commit. >>>>>> One physical write to the log file. >>>>> ... which includes logging of the UNDO >>>>>> One physical write to the data file. >>>>> I rest my case. >>>>> Serge >>>> Only if 1+2=4 in Toronto. And only if you believe all writes >>>> contain the same number of bytes. >>> Oh. So if a write has fewer bytes, it's less of a write? >> Only if you think that writing 80 bytes is more overhead than >> writing 8 bytes. >> >> Perhaps you still think size doesn't matter. <g> > > Never mind the length, feel the girth. > > However, if you're talking about IOs, a 8-byte IO is still an IO, just as > much as an 80-byte IO is an IO. We weren't discussing the number of bytes, > just the number of IOs. > > Reading is everything. The number of IOs is not the only factor in determining the impact on network and IO subsystems but then you know that and are just trying to live up to your nome de plume. -- Daniel A. Morgan University of Washington damorgan@x.washington.edu (replace x with u to respond)
InDeep said: > > > Obnoxio The Clown wrote: >> DA Morgan said: >>> Ian Michael Gumby wrote: >>> >>>> Sorry Serge but I don't think its really fair to be discussing IDS and >>>> in an IDS forum to say ... " ... well if you look at a DB2 benchmark, >>>> I've just proven my point...". >>>> No offense but DB2 isn't IDS .... >>> Given Serge works with DB2, not Informix, his post is understandable. >>> What is not understandable is why IBM doesn't have someone in Serge's >>> position, working with Informix, willing to stand up. >>> >>> Is it because they don't exist? >>> Don't care enough about the product? >>> Or are afraid that saying something will cost them their job? >> >> Maybe they just have better things to do with their days than respond to >> shills and trolls. >> > > That's what we have YOU for. At least I'm not the troll, today. -- Bye now, Obnoxio http://obotheclown.blogspot.com/