db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Store api question: how to ask for RowLocations
Date Wed, 02 Oct 2013 13:38:02 GMT
On 10/1/13 3:40 PM, mike matrigali wrote:
> In general fetchLocation is available for "normal" scans, but obviously
> not available for when store returns bulk set of rows back in the form
> of a hash table.  also GroupFetchScanController have special interfaces
> to return the RowLocation.
>
> Is your problem specific to hash table returns, or are there other cases
> where fetchLocation from a ScanController does not work?
Right now the problem is specific to hash tables. I don't know of any 
other cases which aren't handled by ScanController. However, this 
feature has tripped across a lot of surprises already so the new api may 
be needed elsewhere before I'm done. Can't say yet.

Thanks,
-Rick
>
> On 10/1/2013 10:29 AM, Rick Hillegas wrote:
>> I need some advice about how to design an api for requesting that the
>> Store include RowLocations in the rows that it scans and hands back to
>> the language layer.
>>
>> The immediate problem that I'm working on involves implementing the
>> MERGE statement (DERBY-3155). Part of the implementation involves
>> cooking up a left join between two tables. I need to get back
>> RowLocations for the right table of that join. In a particular problem
>> case which I'm examining, the optimizer picks a HashJoin strategy for
>> the left join. That turns into a HashLeftOuterJoinResultSet at execution
>> time. And that, in turn, involves having the Store create and fill a
>> BackingStoreHashTableFromScan.
>>
>> The BackingStoreHashTableFromScan is created with a scanColumnList (a
>> FormatableBitSet) which specifies some actual columns in the row as well
>> as a trailing column position which is meant to represent the
>> RowLocation. That trailing column position is represented as 1 plus the
>> actual row length. BackingStoreHashTableFromScan doesn't know what to
>> make of that column position and silently ignores it. So clearly either
>> that's the wrong api for asking for RowLocations or
>> BackingStoreHashTableFromScan needs to be taught some new tricks.
>>
>> So the question is this: what's the right way to ask
>> BackingStoreHashTableFromScan to build a hash table whose rows contain
>> some set of real column positions plus a trailing RowLocation column? I
>> may stumble into other situations where I need to ask a scan to put
>> RowLocations into the rows it returns. So it would be good to have a
>> general pattern here for requesting this special column.
>>
>> Thanks,
>> -Rick
>>
>>
>
>


Mime
View raw message