Comments on: Do Storage Indexes Work with Bind Variables?

By: osborne

osborne — Sat, 03 Nov 2012 02:53:32 +0000

Hi Kumar,

Sorting data can affect the compression ratio – so yes the number of blocks could be bigger or smaller depending on the order of the rows.

Kerry

By: Kumar Ramalingam

Kumar Ramalingam — Tue, 30 Oct 2012 18:36:11 +0000

Hi Kerry,
I was testing with EHCC compression and storage indexes. In my testing, first I compressed my subpartitions for query high and I ended up with 74K blocks for about 9M rows. I created another test table with the same structure of the previous (same storage attributes) and loaded the data from the partition mentioned above (that has 9M rows) with sorting on two columns. Now, after firing the query with the predicate on the sorted columns, I could get the storage indexes working perfectly.
But, when I checked the number of blocks occupied for the partition that has the sorted data, it was 20K blocks more than the unsorted partition.
Do you know, from your testing if it shows such a behavior? Would it be a bug? Please help me out on this as you have pulled me out of trouble several times in the past with your rich information on your blog. Thanks in advance.

–Kumar Ramalingam

By: www.rmanbackup.com

www.rmanbackup.com — Tue, 05 Oct 2010 17:36:34 +0000

Thank you so much for sharing this precious information with us.

By: Eric

Eric — Thu, 30 Sep 2010 02:50:25 +0000

Indeed, but then again so is writing queries to obtain a full scan. Great explanation above and thank you.

By: osborne

osborne — Tue, 14 Sep 2010 02:32:18 +0000

Thanks for the update Christo. The implicit conversions are definitely a little counter intuitive.

Kerry

By: Correction on Storage Index blog | The Pythian Blog

Correction on Storage Index blog | The Pythian Blog — Mon, 13 Sep 2010 22:08:28 +0000

[...] is just a quick post to note that I’ve corrected my blog on Storage Indexes here, after a follow up blog from Kerry Osborne indicating an error on my [...]

By: Christo Kutrovsky

Christo Kutrovsky — Mon, 13 Sep 2010 22:04:13 +0000

Hi Kerry,

Thanks for following up on these questions. I’ve updated my blog as well with some extra information as well.

By: Designing for Exadata: Maximizing Storage Indexes Use | The Pythian Blog

Designing for Exadata: Maximizing Storage Indexes Use | The Pythian Blog — Mon, 13 Sep 2010 22:00:59 +0000

[...] for this update goes to Kerry Osborne’s blog post, who did some additional research. As a result, this update comes from [...]

By: osborne

osborne — Mon, 13 Sep 2010 21:09:07 +0000

Good catch Flado. That was the problem. I left the example as is, but if I changed it use the correct column (col2) it behaves as it should, using the storage index.

SYS@LABRAT1> select /* 1111 */ count(*) from kso.skew3 where col2 = :x;

  COUNT(*)
----------
         0

Elapsed: 00:00:00.07

Thanks for pointing that out. Just makes the point a little finer by the way. That point being that implicit conversions can easily disable Storage Indexes. It’s a little counter intuitive since we’re not used to worrying about this issue when we’re expecting full scans anyway.

Kerry

By: Flado

Flado — Mon, 13 Sep 2010 16:52:44 +0000

quote
SYS@LABRAT1> select /* 1111 */ count(*) from kso.skew3 where col1 = :x;
/quote
Is that a copy/paste error or the reason why the index is not used for ’1111′? (note that col1 is of type NUMBER, all other tests in the block use col2)

quote
Any one got any ideas?
/quote
What if you convert the variable explicitly, as in
exec :dd:=’20-OCT-2005′
select count(*) from kso.skew3 where col3 = to_date(:dd,’DD-MON-RRRR’);
?
That’s the “trick” I use for normal indexes…
Cheers!
Flado