Re: C++ equivalent type to Oracle's rowid.
From: Shane <gshanemiller_at_verizon.net>
Date: Tue, 24 Mar 2009 16:56:09 -0700 (PDT)
Message-ID: <2c2867e9-51b5-4ed6-a37e-796b52038d62_at_d19g2000yqb.googlegroups.com>
On Mar 24, 2:49 pm, Robert Klemme <shortcut..._at_googlemail.com> wrote:
> On 24.03.2009 13:44, johnbhur..._at_sbcglobal.net wrote:
>
> > On Mar 24, 12:00 am, Shane <gshanemil..._at_verizon.net> wrote:
> >> What is the C/C++ equivalent to Oracle's rowid?
>
> My spontaneous reaction was "this" which is actually the same concept
> (storage address). But then I read on and...
>
>
>
>
>
> >> Currently I am using OTL 4.0 and passing/returning rowids to Oracle
> >> stored procedures e.g.:
>
> >> insert into ... values( .. ) returning rowid into rw_id; # returning
> >> id
> >> update ... set .. where rowid=ord_id; # passing in id
>
> >> Right now my C/C++ type is char[19].
>
> >> As aside I was benchmarking a design which uses a unique primary index
> >> to perform the updates like this:
>
> >> update ... ser where order_id=ord_id and order_date=ord_date;
>
> >> vs. a design in which there were NO/ZERO indexes and the update was
> >> done like:
>
> >> update ... set .. where rowid=id;
>
> >> Unexpectedly the indexed version generally out performs the rowid
> >> approach. I was thinking that passing around 19 byte rowids and/or
> >> implicit chartorowid()/rowidtochar() were slowing down the rowid
> >> version.
>
> > It has been emphasized for years ( decades even ) to stay away from
> > logic operating on/using rowid's ...
>
> In this particular case: it seems you need two database roundtrips when
> using ROWIDS (i.e. determine the ROWID and then using it for the
> UPDATE). This is almost always slower than using the WHERE part that
> was used to determine the ROWID directly in the UPDATE. I don't see the
> point in using the ROWID here at all.
>
> Kind regards
>
> robert- Hide quoted text -
>
> - Show quoted text -
Date: Tue, 24 Mar 2009 16:56:09 -0700 (PDT)
Message-ID: <2c2867e9-51b5-4ed6-a37e-796b52038d62_at_d19g2000yqb.googlegroups.com>
On Mar 24, 2:49 pm, Robert Klemme <shortcut..._at_googlemail.com> wrote:
> On 24.03.2009 13:44, johnbhur..._at_sbcglobal.net wrote:
>
> > On Mar 24, 12:00 am, Shane <gshanemil..._at_verizon.net> wrote:
> >> What is the C/C++ equivalent to Oracle's rowid?
>
> My spontaneous reaction was "this" which is actually the same concept
> (storage address). But then I read on and...
>
>
>
>
>
> >> Currently I am using OTL 4.0 and passing/returning rowids to Oracle
> >> stored procedures e.g.:
>
> >> insert into ... values( .. ) returning rowid into rw_id; # returning
> >> id
> >> update ... set .. where rowid=ord_id; # passing in id
>
> >> Right now my C/C++ type is char[19].
>
> >> As aside I was benchmarking a design which uses a unique primary index
> >> to perform the updates like this:
>
> >> update ... ser where order_id=ord_id and order_date=ord_date;
>
> >> vs. a design in which there were NO/ZERO indexes and the update was
> >> done like:
>
> >> update ... set .. where rowid=id;
>
> >> Unexpectedly the indexed version generally out performs the rowid
> >> approach. I was thinking that passing around 19 byte rowids and/or
> >> implicit chartorowid()/rowidtochar() were slowing down the rowid
> >> version.
>
> > It has been emphasized for years ( decades even ) to stay away from
> > logic operating on/using rowid's ...
>
> In this particular case: it seems you need two database roundtrips when
> using ROWIDS (i.e. determine the ROWID and then using it for the
> UPDATE). This is almost always slower than using the WHERE part that
> was used to determine the ROWID directly in the UPDATE. I don't see the
> point in using the ROWID here at all.
>
> Kind regards
>
> robert- Hide quoted text -
>
> - Show quoted text -
Three comments:
* Two roundtrips to DB not needed. The rowid is cached by the
application and passed in.
* Still do not know the C/C++ equivalent type to rowid! Else where it
was said that implicit conversions between the underlying type
converting to/from char form are part reason why rowids slow.
I am not wedded to rowids but when speed is total, overwhelming constraint and where 50% of the searches can be replaced by lookups by rowids that are cached in the application anyway, blowing by the index creation and update could begin to count when millions of rows are in play. My tests only considered tables with 100K rows in it.
I'd still like to know the C/C++ equivalent to rowid. Received on Tue Mar 24 2009 - 18:56:09 CDT