Re: friday afternoon query.

Joe,

you are right there will be implicit conversion as you mention but i think it won't be that visible for singleton queries but bulk loads (i.e. millions) you might see a minor penalty. This can be easily measured (if any) using runstats package from asktom site.

Raj

On Fri, Jun 27, 2008 at 3:21 PM, <TESTAJ3_at_nationwide.com> wrote:

>
> Please look at this and tell me what you think:
>
> Last part of each table subpartition definition, the subpartiton column is
> defined as number:
>
> Database 1:
> TABLESPACE "P_PART_MAX" NOCOMPRESS
> ( SUBPARTITION "P_SUBPART_MAX_EAGLE_PACE" VALUES (4)
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PAM" VALUES (23)
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PAS" VALUES (31)
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PMA" VALUES (60)
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_DEFAULT" VALUES (default)
> TABLESPACE "P_PART_MAX") )
> MONITORING ;
>
>
> Database 2:
> TABLESPACE "P_PART_MAX"
> ( SUBPARTITION "P_SUBPART_MAX_EAGLE_PACE" VALUES ('4')
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PAM" VALUES ('23')
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PAS" VALUES ('31')
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_PMA" VALUES ('60')
> TABLESPACE "P_PART_MAX",
> SUBPARTITION "P_SUBPART_MAX_DEFAULT" VALUES (default)
> TABLESPACE "P_PART_MAX") ) ;
>
>
> My take on this is since the true datatype of the column is number, will
> oracle have to do an implicit conversion of the data during an insert to
> varchar to figure out which subparititon to drop the row into and will it
> incur a performance hit??
>
>
>
>
> Thanks, Joe
>
> ---------------------------------------
> You can have it: Fast, Right or Cheap, pick 2 of the 3.
> Fast + Right is Expensive
> Fast + Cheap will be incorrect.
> Right + Cheap will take a while.

-- 
-----
Best regards
Rjamya

--
http://www.freelists.org/webpage/oracle-l