Comments on: List partitions

By: Log Buffer #205, A Carnival of the Vanities for DBAs

Log Buffer #205, A Carnival of the Vanities for DBAs — Wed, 13 Feb 2013 16:54:59 +0000

[...] Lewis does a little thought experiment with list [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 30 Nov 2010 22:50:06 +0000

Peter,

Thanks for the follow-up.

By: Pete Scott

Pete Scott — Tue, 30 Nov 2010 20:32:54 +0000

In a few idle moments I managed to find a suitable list partitioned table to test my query approach on – the case statement variant did not produce an appreciably different query plan to the simple not equals case. It appeared marginally faster, but not by anything that could be regarded as significant.

The key thing about the test was it was just that a test – an idea (no matter how ‘off the wall’) is not dismissed out of hand but tested and compared to other approaches – it is all about the process of discovery.

By: Pete Scott

Pete Scott — Sat, 27 Nov 2010 23:11:37 +0000

Sorry for the late comment
Looking for the NOT is a common occurrence in my world. A few years back I came across (and blogged) an alternate way to construct this type of query.
select count(*) from area_sales where area != 'England' ;
could be changed to
select count(*) from area_sales where case when area = 'England' then 1 else 0 end = 0
Of course the case I wrote about was not really about partitioning but it does represent an alternative way to preset a query – and worthy of testing to see if it better approximates what is known of the data. It certainly is not a “one size fits all” solution – test, test, test!

By: Log Buffer #206, A Carnival of the Vanities for DBAs | The Pythian Blog

Log Buffer #206, A Carnival of the Vanities for DBAs | The Pythian Blog — Mon, 15 Nov 2010 06:27:51 +0000

[...] Lewis explains how he tests list partitions, a post which gives an excellent review on how one should go about testing new features in [...]

By: Local Indexes – 2 « Oracle Scratchpad

Local Indexes – 2 « Oracle Scratchpad — Sun, 14 Nov 2010 17:42:26 +0000

[...] the cost of using the index t1_id to access the data ? A2: As I pointed out in an earlier note on list partitioned tables, Oracle doesn’t recognise the (obvious to the human eye) option for partition pruning in this [...]

By: Local Indexes « Oracle Scratchpad

Local Indexes « Oracle Scratchpad — Thu, 11 Nov 2010 22:45:43 +0000

[...] a recent article about list partitioned tables I raised some questions about the cases where the optimizer can’t (yet) do partitioning [...]

By: Hemant K Chitale

Hemant K Chitale — Tue, 09 Nov 2010 09:21:09 +0000

My comment was in reply to Christo’s : “Oracle is doing partition *elimination*, yet the most basic form – list partitions – cannot process even simple “not” conditions to eliminate partition from scanning”
I pointed out that Oracle does Pruning. So it doesn’t do “Elimination” directly but by way of Pruning.

There’s one reference to Elimination at http://download.oracle.com/docs/cd/E11882_01/server.112/e16508/schemaob.htm#CNCPT88868 which goes “Both types of indexes can take advantage of partition elimination (also called partition pruning), which occurs when the optimizer speeds data access by excluding partitions from consideration” when talking of Local Indexes.

By: Jonathan Lewis

Jonathan Lewis — Mon, 08 Nov 2010 18:35:45 +0000

Hemant, Are you making a distinction between "elimination" and "pruning" or just pointing out that I ought to be using the term "pruning" rather than "elimination" since that's the term used virtually everywhere in the manuals ? There may be some variation across versions in how well Oracle can handle the IN-list, but here's the execution plan for the ('England','Ireland','Wales') query from an 11.1.0.6 database: [sourcecode gutter="false"] ------------------------------------------------------------------------------------- | Id | Operation | Name | Rows | Bytes | Cost | Pstart| Pstop | ------------------------------------------------------------------------------------- | 0 | SELECT STATEMENT | | 1 | 8 | 64 | | | | 1 | SORT AGGREGATE | | 1 | 8 | | | | | 2 | PARTITION LIST INLIST| | 22500 | 175K| 64 |KEY(I) |KEY(I) | | 3 | TABLE ACCESS FULL | AREA_SALES | 22500 | 175K| 64 |KEY(I) |KEY(I) | ------------------------------------------------------------------------------------- [/sourcecode] Note - there is NO predicate section. So the optimizer has deduced that the whole of the England partition is necessary and sufficient to answer the 'England' key, and so on for the other two values. Partition pruning has been applied with perfect precision in this case.

By: Hemant K Chitale

Hemant K Chitale — Mon, 08 Nov 2010 06:17:18 +0000

It’s not really able to do “Partition Elimination”. It can do “Partition Pruning” to identify that it needs 3 of 4 partitions (but doesn’t know identify the partitions in the case of “area in ( ‘England’, ‘Ireland’, ‘Wales’)”.