Is anyone else pining for a multi-table isolated batch scanner, or is itjust me? I like the automatic parallelism and balancing of the batchscanner, but I'm looking to maintain server-side state in my iterators overlong-running scans. I would also like to scan over multiple tablesconcurrently. Has anyone tried hacking something together with a pool ofnon-batch scanners?

How are you expecting to get results back? Guava's Iterables could concat abunch of a Scanners together, if you didn't care about the throughputaspect of it and simply wanted results from multiple tables.

> Is anyone else pining for a multi-table isolated batch scanner, or is it> just me? I like the automatic parallelism and balancing of the batch> scanner, but I'm looking to maintain server-side state in my iterators over> long-running scans. I would also like to scan over multiple tables> concurrently. Has anyone tried hacking something together with a pool of> non-batch scanners?>> Adam>

> How are you expecting to get results back? Guava's Iterables could concat a> bunch of a Scanners together, if you didn't care about the throughput> aspect of it and simply wanted results from multiple tables.>> On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>> > Is anyone else pining for a multi-table isolated batch scanner, or is it> > just me? I like the automatic parallelism and balancing of the batch> > scanner, but I'm looking to maintain server-side state in my iterators> over> > long-running scans. I would also like to scan over multiple tables> > concurrently. Has anyone tried hacking something together with a pool of> > non-batch scanners?> >> > Adam> >>

It seems like you're talking about two features at once:1) Multi-table batch scanner.2) Scan Isolation on batch scanners like we have on regular scanners.Is that correct?

I can see the utility of a multi-table batch scanner, but I haven'tseen a compelling need for implementing isolation on thebatch-scanners. Do you have a use case in mind for that?

Also, it seems that your use case for isolation is not so much theisolated reads, but the statefulness of the iterator stack on theserver side. Is this correct? If so, I'm even more curious about youruse case for this, since that statefulness is only guaranteed per-row.--Christopher L Tubbs IIhttp://gravatar.com/ctubbsiiOn Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> Thanks Bill,>> I care about latency and throughput. First available result ordering is> fine, though.>> Does Guava just chain through a collection of iterators, completing one> then moving to the next?>> Adam>>>> On Mon, Apr 15, 2013 at 3:06 PM, William Slacum <> [EMAIL PROTECTED]> wrote:>>> How are you expecting to get results back? Guava's Iterables could concat a>> bunch of a Scanners together, if you didn't care about the throughput>> aspect of it and simply wanted results from multiple tables.>>>> On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>>>> > Is anyone else pining for a multi-table isolated batch scanner, or is it>> > just me? I like the automatic parallelism and balancing of the batch>> > scanner, but I'm looking to maintain server-side state in my iterators>> over>> > long-running scans. I would also like to scan over multiple tables>> > concurrently. Has anyone tried hacking something together with a pool of>> > non-batch scanners?>> >>> > Adam>> >>>

The current thrift RPCs may support multiple tables. The RPCs takekey extents. The only caveat is that the same options (columns,iterators, auths) would have to be used for all tables.

On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> Is anyone else pining for a multi-table isolated batch scanner, or is it> just me? I like the automatic parallelism and balancing of the batch> scanner, but I'm looking to maintain server-side state in my iterators over> long-running scans. I would also like to scan over multiple tables> concurrently. Has anyone tried hacking something together with a pool of> non-batch scanners?>> Adam

The desire for isolation stems from the desire to amortize some computationover a number of results. Say it takes 5 seconds to compute an intersectionof a couple of sets within the iterators, and then streaming back theresults takes a minute or so. If I have to redo the 5 second computationmany times, as in to support the reconstruction of the iterator tree, thenthat computation may start to dominate my query performance. Primarily,this means I need to be able to continue a scan without having to rebuildthe iterators. Isolation in the scanner has that side effect. Properisolation would be a "nice-to-have", but I can deal with not having it.

> Adam->> It seems like you're talking about two features at once:> 1) Multi-table batch scanner.> 2) Scan Isolation on batch scanners like we have on regular scanners.> Is that correct?>> I can see the utility of a multi-table batch scanner, but I haven't> seen a compelling need for implementing isolation on the> batch-scanners. Do you have a use case in mind for that?>> Also, it seems that your use case for isolation is not so much the> isolated reads, but the statefulness of the iterator stack on the> server side. Is this correct? If so, I'm even more curious about your> use case for this, since that statefulness is only guaranteed per-row.>>> --> Christopher L Tubbs II> http://gravatar.com/ctubbsii>>> On Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> > Thanks Bill,> >> > I care about latency and throughput. First available result ordering is> > fine, though.> >> > Does Guava just chain through a collection of iterators, completing one> > then moving to the next?> >> > Adam> >> >> >> > On Mon, Apr 15, 2013 at 3:06 PM, William Slacum <> > [EMAIL PROTECTED]> wrote:> >> >> How are you expecting to get results back? Guava's Iterables could> concat a> >> bunch of a Scanners together, if you didn't care about the throughput> >> aspect of it and simply wanted results from multiple tables.> >>> >> On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> >>> >> > Is anyone else pining for a multi-table isolated batch scanner, or is> it> >> > just me? I like the automatic parallelism and balancing of the batch> >> > scanner, but I'm looking to maintain server-side state in my iterators> >> over> >> > long-running scans. I would also like to scan over multiple tables> >> > concurrently. Has anyone tried hacking something together with a pool> of> >> > non-batch scanners?> >> >> >> > Adam> >> >> >>>

On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> Chris,>> The desire for isolation stems from the desire to amortize some computation> over a number of results. Say it takes 5 seconds to compute an intersection

Would increasing the size of the key/value buffer help in your case?The iterator stack is not torn down until that buffer fills up or theend of tablet is reached. Are you concerned about the cost ofreconstructing the iterator stack across tablets?

> of a couple of sets within the iterators, and then streaming back the> results takes a minute or so. If I have to redo the 5 second computation> many times, as in to support the reconstruction of the iterator tree, then> that computation may start to dominate my query performance. Primarily,> this means I need to be able to continue a scan without having to rebuild> the iterators. Isolation in the scanner has that side effect. Proper> isolation would be a "nice-to-have", but I can deal with not having it.>> Adam>>>> On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]> wrote:>>> Adam->>>> It seems like you're talking about two features at once:>> 1) Multi-table batch scanner.>> 2) Scan Isolation on batch scanners like we have on regular scanners.>> Is that correct?>>>> I can see the utility of a multi-table batch scanner, but I haven't>> seen a compelling need for implementing isolation on the>> batch-scanners. Do you have a use case in mind for that?>>>> Also, it seems that your use case for isolation is not so much the>> isolated reads, but the statefulness of the iterator stack on the>> server side. Is this correct? If so, I'm even more curious about your>> use case for this, since that statefulness is only guaranteed per-row.>>>>>> -->> Christopher L Tubbs II>> http://gravatar.com/ctubbsii>>>>>> On Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>> > Thanks Bill,>> >>> > I care about latency and throughput. First available result ordering is>> > fine, though.>> >>> > Does Guava just chain through a collection of iterators, completing one>> > then moving to the next?>> >>> > Adam>> >>> >>> >>> > On Mon, Apr 15, 2013 at 3:06 PM, William Slacum <>> > [EMAIL PROTECTED]> wrote:>> >>> >> How are you expecting to get results back? Guava's Iterables could>> concat a>> >> bunch of a Scanners together, if you didn't care about the throughput>> >> aspect of it and simply wanted results from multiple tables.>> >>>> >> On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>> >>>> >> > Is anyone else pining for a multi-table isolated batch scanner, or is>> it>> >> > just me? I like the automatic parallelism and balancing of the batch>> >> > scanner, but I'm looking to maintain server-side state in my iterators>> >> over>> >> > long-running scans. I would also like to scan over multiple tables>> >> > concurrently. Has anyone tried hacking something together with a pool>> of>> >> > non-batch scanners?>> >> >>> >> > Adam>> >> >>> >>>>

In this case we're filling the buffer before we can amortize the searchcost. We're using a document-partitioned table design and we have to do alocal sort before we can get the first result.

I have found that increasing the buffer size also increases the latency forgetting the first results. This application is both latency and throughputsensitive. In addition, increasing the batch size too much puts significantmemory requirements on the process running the batch scanner.

> On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> > Chris,> >> > The desire for isolation stems from the desire to amortize some> computation> > over a number of results. Say it takes 5 seconds to compute an> intersection>> Would increasing the size of the key/value buffer help in your case?> The iterator stack is not torn down until that buffer fills up or the> end of tablet is reached. Are you concerned about the cost of> reconstructing the iterator stack across tablets?>> > of a couple of sets within the iterators, and then streaming back the> > results takes a minute or so. If I have to redo the 5 second computation> > many times, as in to support the reconstruction of the iterator tree,> then> > that computation may start to dominate my query performance. Primarily,> > this means I need to be able to continue a scan without having to rebuild> > the iterators. Isolation in the scanner has that side effect. Proper> > isolation would be a "nice-to-have", but I can deal with not having it.> >> > Adam> >> >> >> > On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]>> wrote:> >> >> Adam-> >>> >> It seems like you're talking about two features at once:> >> 1) Multi-table batch scanner.> >> 2) Scan Isolation on batch scanners like we have on regular scanners.> >> Is that correct?> >>> >> I can see the utility of a multi-table batch scanner, but I haven't> >> seen a compelling need for implementing isolation on the> >> batch-scanners. Do you have a use case in mind for that?> >>> >> Also, it seems that your use case for isolation is not so much the> >> isolated reads, but the statefulness of the iterator stack on the> >> server side. Is this correct? If so, I'm even more curious about your> >> use case for this, since that statefulness is only guaranteed per-row.> >>> >>> >> --> >> Christopher L Tubbs II> >> http://gravatar.com/ctubbsii> >>> >>> >> On Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> >> > Thanks Bill,> >> >> >> > I care about latency and throughput. First available result ordering> is> >> > fine, though.> >> >> >> > Does Guava just chain through a collection of iterators, completing> one> >> > then moving to the next?> >> >> >> > Adam> >> >> >> >> >> >> >> > On Mon, Apr 15, 2013 at 3:06 PM, William Slacum <> >> > [EMAIL PROTECTED]> wrote:> >> >> >> >> How are you expecting to get results back? Guava's Iterables could> >> concat a> >> >> bunch of a Scanners together, if you didn't care about the throughput> >> >> aspect of it and simply wanted results from multiple tables.> >> >>> >> >> On Mon, Apr 15, 2013 at 3:00 PM, Adam Fuchs <[EMAIL PROTECTED]>> wrote:> >> >>> >> >> > Is anyone else pining for a multi-table isolated batch scanner, or> is> >> it> >> >> > just me? I like the automatic parallelism and balancing of the> batch> >> >> > scanner, but I'm looking to maintain server-side state in my> iterators> >> >> over> >> >> > long-running scans. I would also like to scan over multiple tables> >> >> > concurrently. Has anyone tried hacking something together with a> pool> >> of> >> >> > non-batch scanners?> >> >> >> >> >> > Adam> >> >> >> >> >>> >>>

Pushing the problem from the client to the server increases thecomplexity. I would be concerned with multiple concurrent scans that aresaving state. The server side state will compete for tserver applicationmemory. I would assume that you would have to build some feature to restrictthe amount of memory that the state can consume.

In this case we're filling the buffer before we can amortize the searchcost. We're using a document-partitioned table design and we have to do alocal sort before we can get the first result.

I have found that increasing the buffer size also increases the latency forgetting the first results. This application is both latency and throughputsensitive. In addition, increasing the batch size too much puts significantmemory requirements on the process running the batch scanner.

> On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> > Chris,> >> > The desire for isolation stems from the desire to amortize some> computation> > over a number of results. Say it takes 5 seconds to compute an> intersection>> Would increasing the size of the key/value buffer help in your case?> The iterator stack is not torn down until that buffer fills up or the > end of tablet is reached. Are you concerned about the cost of > reconstructing the iterator stack across tablets?>> > of a couple of sets within the iterators, and then streaming back > > the results takes a minute or so. If I have to redo the 5 second > > computation many times, as in to support the reconstruction of the > > iterator tree,> then> > that computation may start to dominate my query performance. > > Primarily, this means I need to be able to continue a scan without > > having to rebuild the iterators. Isolation in the scanner has that > > side effect. Proper isolation would be a "nice-to-have", but I can dealwith not having it.> >> > Adam> >> >> >> > On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]>> wrote:> >> >> Adam-> >>> >> It seems like you're talking about two features at once:> >> 1) Multi-table batch scanner.> >> 2) Scan Isolation on batch scanners like we have on regular scanners.> >> Is that correct?> >>> >> I can see the utility of a multi-table batch scanner, but I haven't > >> seen a compelling need for implementing isolation on the > >> batch-scanners. Do you have a use case in mind for that?> >>> >> Also, it seems that your use case for isolation is not so much the > >> isolated reads, but the statefulness of the iterator stack on the > >> server side. Is this correct? If so, I'm even more curious about > >> your use case for this, since that statefulness is only guaranteedper-row.> >>> >>> >> --> >> Christopher L Tubbs II> >> http://gravatar.com/ctubbsii> >>> >>> >> On Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> >> > Thanks Bill,> >> >> >> > I care about latency and throughput. First available result > >> > ordering> is> >> > fine, though.> >> >> >> > Does Guava just chain through a collection of iterators, > >> > completing> one> >> > then moving to the next?> >> >> >> > Adam> >> >> >> >> >> >> >> > On Mon, Apr 15, 2013 at 3:06 PM, William Slacum < > >> > [EMAIL PROTECTED]> wrote:> >> >> >> >> How are you expecting to get results back? Guava's Iterables tables.

You are absolutely right that the server-side space usage is a big concern.One of the ways that we conserve space on the server is to do multiplepasses in which we scan a bunch of data and keep only part of it. Thisgives us a trade-off between memory usage and cpu time. The space that weuse on the server gets amplified by a secondary lookup before data getsback to the client. We've found that the optimal amount of memory to use onthe server is much larger that what can be processed before the scan bufferfills, although it's still only on the order of a couple of megabytes.

Thanks for the suggestions, everyone. Keep em coming! I'm going to try outa couple of prototypes and see where they get me.

> ---> I have found that increasing the buffer size also increases the> latency> for getting the first results.>> We have found that to be true also, we do the opposite to get to the> first> result faster. Of course we are not performing a local sort first.>> ---> increasing the batch size too much puts significant memory> requirements> on the process running the batch scanner>> Pushing the problem from the client to the server increases the> complexity. I would be concerned with multiple concurrent scans that are> saving state. The server side state will compete for tserver application> memory. I would assume that you would have to build some feature to> restrict> the amount of memory that the state can consume.>> -----Original Message-----> From: Adam Fuchs [mailto:[EMAIL PROTECTED]]> Sent: Monday, April 15, 2013 6:19 PM> To: [EMAIL PROTECTED]> Subject: Re: multi-table isolated batch scanner>> Keith,>> In this case we're filling the buffer before we can amortize the search> cost. We're using a document-partitioned table design and we have to do a> local sort before we can get the first result.>> I have found that increasing the buffer size also increases the latency for> getting the first results. This application is both latency and throughput> sensitive. In addition, increasing the batch size too much puts significant> memory requirements on the process running the batch scanner.>> Adam>>>> On Mon, Apr 15, 2013 at 5:33 PM, Keith Turner <[EMAIL PROTECTED]> wrote:>> > On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> > > Chris,> > >> > > The desire for isolation stems from the desire to amortize some> > computation> > > over a number of results. Say it takes 5 seconds to compute an> > intersection> >> > Would increasing the size of the key/value buffer help in your case?> > The iterator stack is not torn down until that buffer fills up or the> > end of tablet is reached. Are you concerned about the cost of> > reconstructing the iterator stack across tablets?> >> > > of a couple of sets within the iterators, and then streaming back> > > the results takes a minute or so. If I have to redo the 5 second> > > computation many times, as in to support the reconstruction of the> > > iterator tree,> > then> > > that computation may start to dominate my query performance.> > > Primarily, this means I need to be able to continue a scan without> > > having to rebuild the iterators. Isolation in the scanner has that> > > side effect. Proper isolation would be a "nice-to-have", but I can deal> with not having it.> > >> > > Adam> > >> > >> > >> > > On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]>> > wrote:> > >> > >> Adam-> > >>> > >> It seems like you're talking about two features at once:> > >> 1) Multi-table batch scanner.> > >> 2) Scan Isolation on batch scanners like we have on regular scanners.> > >> Is that correct?> > >>> > >> I can see the utility of a multi-table batch scanner, but I haven't> > >> seen a compelling need for implementing isolation on the> > >> batch-scanners. Do you have a use case in mind for that?

On Mon, Apr 15, 2013 at 6:19 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> Keith,>> In this case we're filling the buffer before we can amortize the search> cost. We're using a document-partitioned table design and we have to do a> local sort before we can get the first result.>

I am not sure exactly what you are doing. To me it sounds like youmay be doing the following, but not sure.

* Seeking N iterators * Doing what the intersecting iterator does, joining docids orseeking iterators * Collecting a set of key values (docids or documents?) and sortingthem? How much is collected before sort? Why sort? Is filteringdone after the sort?

Or did you meant something else by 'local sort' ? like a sort on theclient side? But this does not seem the entire story as you mentionedsomething about multiple passes. Are you hash partitioning the data?Are you building something in memoery besides the buffered outputdata?> I have found that increasing the buffer size also increases the latency for> getting the first results. This application is both latency and throughput> sensitive. In addition, increasing the batch size too much puts significant> memory requirements on the process running the batch scanner.>> Adam>>>> On Mon, Apr 15, 2013 at 5:33 PM, Keith Turner <[EMAIL PROTECTED]> wrote:>>> On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>> > Chris,>> >>> > The desire for isolation stems from the desire to amortize some>> computation>> > over a number of results. Say it takes 5 seconds to compute an>> intersection>>>> Would increasing the size of the key/value buffer help in your case?>> The iterator stack is not torn down until that buffer fills up or the>> end of tablet is reached. Are you concerned about the cost of>> reconstructing the iterator stack across tablets?>>>> > of a couple of sets within the iterators, and then streaming back the>> > results takes a minute or so. If I have to redo the 5 second computation>> > many times, as in to support the reconstruction of the iterator tree,>> then>> > that computation may start to dominate my query performance. Primarily,>> > this means I need to be able to continue a scan without having to rebuild>> > the iterators. Isolation in the scanner has that side effect. Proper>> > isolation would be a "nice-to-have", but I can deal with not having it.>> >>> > Adam>> >>> >>> >>> > On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]>>> wrote:>> >>> >> Adam->> >>>> >> It seems like you're talking about two features at once:>> >> 1) Multi-table batch scanner.>> >> 2) Scan Isolation on batch scanners like we have on regular scanners.>> >> Is that correct?>> >>>> >> I can see the utility of a multi-table batch scanner, but I haven't>> >> seen a compelling need for implementing isolation on the>> >> batch-scanners. Do you have a use case in mind for that?>> >>>> >> Also, it seems that your use case for isolation is not so much the>> >> isolated reads, but the statefulness of the iterator stack on the>> >> server side. Is this correct? If so, I'm even more curious about your>> >> use case for this, since that statefulness is only guaranteed per-row.>> >>>> >>>> >> -->> >> Christopher L Tubbs II>> >> http://gravatar.com/ctubbsii>> >>>> >>>> >> On Mon, Apr 15, 2013 at 3:10 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:>> >> > Thanks Bill,>> >> >>> >> > I care about latency and throughput. First available result ordering>> is>> >> > fine, though.>> >> >>> >> > Does Guava just chain through a collection of iterators, completing>> one>> >> > then moving to the next?>> >> >>> >> > Adam>> >> >>> >> >>> >> >>> >> > On Mon, Apr 15, 2013 at 3:06 PM, William Slacum <>> >> > [EMAIL PROTECTED]> wrote:>> >> >>> >> >> How are you expecting to get results back? Guava's Iterables could>> >> concat a>> >> >> bunch of a Scanners together, if you didn't care about the throughput

I'm essentially performing a local sort-merge inner join (local meaningwithin one tablet at a time). This is similar to what the intersectingiterator does, but I'm doing it on data that is not already sorted.Applications of this include any kind of indexed boolean logic predicatesearch in which one or more of the predicates cannot be tied to an exactterm, but can be tied to a range of terms. Wildcard searches, multi-hopgraph searches, and range queries all fit this pattern.

After the join there is additional processing done on the results. I wouldlike to keep some of the intermediate data buffered, like the sorted set ofIDs that match a predicate, even though these are not directly part of theoutput data. The multiple passes are needed for when the intermediate datais too big to hold in memory (while maintaining concurrency, etc.), butthey don't really complicate the underlying problem.

> On Mon, Apr 15, 2013 at 6:19 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> > Keith,> >> > In this case we're filling the buffer before we can amortize the search> > cost. We're using a document-partitioned table design and we have to do a> > local sort before we can get the first result.> >>> I am not sure exactly what you are doing. To me it sounds like you> may be doing the following, but not sure.>> * Seeking N iterators> * Doing what the intersecting iterator does, joining docids or> seeking iterators> * Collecting a set of key values (docids or documents?) and sorting> them? How much is collected before sort? Why sort? Is filtering> done after the sort?>> Or did you meant something else by 'local sort' ? like a sort on the> client side? But this does not seem the entire story as you mentioned> something about multiple passes. Are you hash partitioning the data?> Are you building something in memoery besides the buffered output> data?>>> > I have found that increasing the buffer size also increases the latency> for> > getting the first results. This application is both latency and> throughput> > sensitive. In addition, increasing the batch size too much puts> significant> > memory requirements on the process running the batch scanner.> >> > Adam> >> >> >> > On Mon, Apr 15, 2013 at 5:33 PM, Keith Turner <[EMAIL PROTECTED]> wrote:> >> >> On Mon, Apr 15, 2013 at 5:06 PM, Adam Fuchs <[EMAIL PROTECTED]> wrote:> >> > Chris,> >> >> >> > The desire for isolation stems from the desire to amortize some> >> computation> >> > over a number of results. Say it takes 5 seconds to compute an> >> intersection> >>> >> Would increasing the size of the key/value buffer help in your case?> >> The iterator stack is not torn down until that buffer fills up or the> >> end of tablet is reached. Are you concerned about the cost of> >> reconstructing the iterator stack across tablets?> >>> >> > of a couple of sets within the iterators, and then streaming back the> >> > results takes a minute or so. If I have to redo the 5 second> computation> >> > many times, as in to support the reconstruction of the iterator tree,> >> then> >> > that computation may start to dominate my query performance.> Primarily,> >> > this means I need to be able to continue a scan without having to> rebuild> >> > the iterators. Isolation in the scanner has that side effect. Proper> >> > isolation would be a "nice-to-have", but I can deal with not having> it.> >> >> >> > Adam> >> >> >> >> >> >> >> > On Mon, Apr 15, 2013 at 4:13 PM, Christopher <[EMAIL PROTECTED]>> >> wrote:> >> >> >> >> Adam-> >> >>> >> >> It seems like you're talking about two features at once:> >> >> 1) Multi-table batch scanner.> >> >> 2) Scan Isolation on batch scanners like we have on regular scanners.> >> >> Is that correct?> >> >>> >> >> I can see the utility of a multi-table batch scanner, but I haven't> >> >> seen a compelling need for implementing isolation on the

NEW: Monitor These Apps!

All projects made searchable here are trademarks of the Apache Software Foundation.
Service operated by Sematext