Re: Early 11g Advanced Table Compression #'s

The reason I made my comment was the fact that you specifically mentioned OLTP performance and the use of compression with COMPRESS FOR ALL OPERATIONS. Addressing the last first. Many people copy tables and use export/import (though since 10g expdp/impdp would be recommended). Both of these operations are best done leveraging a direct load and would fall into the "regular" compress or in 11g also known as "COMPRESS FOR DIRECT_LOAD OPERATIONS". Perhaps the confusion on my part (and I'm not just trying to flame) is how any of your tests would leverage the "FOR ALL" compression (new in 11g) vs. "DIRECT_LOAD". Perhaps you could try all 3 test cases. The reason I mention this is there may be different code path that is used for the different types of compression and the different operations in your tests do not attempt to demonstrate this and may demonstrate different behavior on each.

I would argue that 1000 users updating 100 rows is not equivalent to 1 user updating 100,000 rows. They are different tests and while the said results may be comparable, by no means should they be assumed to be equal.

Also, if you are inclined to make performance claims I would advise you take an approach like that of Jonathan Lewis & Tom Kyte, doing exhaustive testing, demonstrating reproducible results, and publishing your tests so that all can attempt to reproduce them on their own. Anything less is probably insufficient to draw meaningful conclusions from.

On 8/17/07, Roby Sherman <rxsherm_at_gmail.com> wrote:
> Granted, OLTP is more about "individual" transactions (gee I guess I
> should have had a TPCC generator in my pocket), but I would also
> argue that updating 100,000 rows should not be a "big deal" either,
> NOT SLOWER IN TERMS OF ORDERS OF MAGNITUDE. Whether 1 transaction
> does it or 1000 transactions are updating 100 rows each (which is
> actually quite common in some of our systems). Besides, what, you
> never copy table data or export/import data in OLTP environments?
> Please.
>
> --R
>
>
> On Aug 17, 2007, at 8:00 AM, Greg Rahn wrote:
>
> > Could you explain exactly how any these tests reflect any type of OLTP
> > workload? That is the new thing in 11g correct that you are
> > attempting to demonstrate performance on, correct? Rather than
> > commenting that the advanced compression is "quite horrible" I'd
> > comment that your choice of tests are quite horrible.
> >
> > On 8/17/07, Roby Sherman <rxsherm_at_interealm.com> wrote:
> >> Seems my mailer has cut off the apostrophe from the URL... It
> >> should be:
> >>
> >> http://web.mac.com/tikimac/iWeb/silicon/Roby_Sherman/
> >> Oracle_Certifiable/Entries/2007/8/16_11G_TABLE_COMPRESSION_-_Don%
> >> E2%80%99t_Believe_the_Hype.html
> >>
> >>
> >>
> >>
> >> On Aug 17, 2007, at 7:14 AM, Roby Sherman wrote:
> >>
> >> For anyone interested, I ran some very quick benchmarks on 11g's new
> >> Advanced Compression table option COMPRESS FOR ALL OPERATIONS that
> >> Oracle is
> >> claiming was "specifically written to create only the most
> >> 'minimal' of
> >> performance impacts in OLTP environments.
> >>
> >> The results are here:
> >> http://web.mac.com/tikimac/iWeb/silicon/Roby_Sherman/
> >> Oracle_Certifiable/Entries/2007/8/16_11G_TABLE_COMPRESSION_-
> >> _Don't_Believe_the_Hype.html
> >>
> >> I guess their definition of minimal and my definition of minimal
> >> must be
> >> different... Anyway, if you're interested in this feature, feel
> >> free to take
> >> a quick look!
> >>
> >> --Roby
> >>
> >>
> >>
> >
> >
> > --
> > Regards,
> >
> > Greg Rahn
> > http://structureddata.org
>
>

-- 
Regards,

Greg Rahn
http://structureddata.org
--
http://www.freelists.org/webpage/oracle-l