phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ankit Singhal (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (PHOENIX-3161) Check possibility of moving rebuilding code to coprocessor of data table.
Date Tue, 18 Oct 2016 10:05:59 GMT

    [ https://issues.apache.org/jira/browse/PHOENIX-3161?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15585071#comment-15585071
] 

Ankit Singhal commented on PHOENIX-3161:
----------------------------------------

bq. Does the HBase copy constructor not maintain the rawScan and cacheBlocks values correctly?
If not can you comment there and reference the HBase bug for those?
Yes, Scan copy constructor is copying attributes and cachBlocks property. so removed the extra
updates to newScan from patch.

bq. Don't change the setTimeRange(Scan,long) method, but use the setTimeRange(Scan,long,long)
method instead. I'm not sure all the callers would expect the min time range to come from
the Scan passed in. Will that work for you?
Yes, updated the patch to use setTimeRange(Scan,long,long) ,though setTimeRange(Scan,long)
was getting used by PostDDLCompiler.

bq. I don't think this fix is correct (and maybe you already made a related fixed that we
should look at too, though perhaps I reworked that already?). We want minTimeStamp to be the
smallest value of all the kv.getTimestamp() we see. It's basically "how far back in time do
we need to query".
We have already fix it in other JIRA(PHOENIX-3331), the change was to get minTimeStamp of
all KVs only.
{code}
-   if (minTimeStamp == 0 || (kv.getTimestamp() >= 0 && minTimeStamp < kv.getTimestamp()))
{
+                            if (minTimeStamp == 0 || (kv.getTimestamp() >= 0 &&
minTimeStamp > kv.getTimestamp())) {
{code}

bq. I thought that region.batchMutate() won't invoke coprocessors like htable.batch() does?

Yes ,it call coprocessors like htable.batch().

bq. Do existing tests pass with your patch? 
yes all tests were passed. MutableIndexIT is mainly testing this.

bq. FWIW, we'd like to change the coprocessor code to use htable.batch() instead (see PHOENIX-3271)
so that we can execute UPSERT SELECT on the server-side instead of bringing all the data back
to the client-side, even if the source and target tables are different (if auto commit is
on). Would love it if you could tackle that one next.
sure, I can try to take it next.







> Check possibility of moving rebuilding code to coprocessor of data table.
> -------------------------------------------------------------------------
>
>                 Key: PHOENIX-3161
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-3161
>             Project: Phoenix
>          Issue Type: Sub-task
>            Reporter: Ankit Singhal
>            Assignee: Ankit Singhal
>             Fix For: 4.9.0
>
>         Attachments: PHOENIX-3161.patch, PHOENIX-3161_v1.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message