Re: Early 11g Advanced Table Compression #'s
- From: "Greg Rahn" <greg@xxxxxxxxxxxxxxxxxx>
- To: "Roby Sherman" <rxsherm@xxxxxxxxx>
- Date: Fri, 17 Aug 2007 18:16:20 +0300
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@xxxxxxxxx> 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@xxxxxxxxxxxxx> 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
--
//www.freelists.org/webpage/oracle-l
Other related posts:
