From dev-return-51407-archive-asf-public=cust-asf.ponee.io@phoenix.apache.org Wed May 2 03:22:10 2018 Return-Path: X-Original-To: archive-asf-public@cust-asf.ponee.io Delivered-To: archive-asf-public@cust-asf.ponee.io Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by mx-eu-01.ponee.io (Postfix) with SMTP id 6F0B0180645 for ; Wed, 2 May 2018 03:22:10 +0200 (CEST) Received: (qmail 67443 invoked by uid 500); 2 May 2018 01:22:09 -0000 Mailing-List: contact dev-help@phoenix.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@phoenix.apache.org Delivered-To: mailing list dev@phoenix.apache.org Received: (qmail 67432 invoked by uid 99); 2 May 2018 01:22:09 -0000 Received: from pnap-us-west-generic-nat.apache.org (HELO spamd3-us-west.apache.org) (209.188.14.142) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 May 2018 01:22:09 +0000 Received: from localhost (localhost [127.0.0.1]) by spamd3-us-west.apache.org (ASF Mail Server at spamd3-us-west.apache.org) with ESMTP id B3FD8180709 for ; Wed, 2 May 2018 01:22:08 +0000 (UTC) X-Virus-Scanned: Debian amavisd-new at spamd3-us-west.apache.org X-Spam-Flag: NO X-Spam-Score: -109.511 X-Spam-Level: X-Spam-Status: No, score=-109.511 tagged_above=-999 required=6.31 tests=[ENV_AND_HDR_SPF_MATCH=-0.5, KAM_ASCII_DIVIDERS=0.8, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_SPF_WL=-7.5, USER_IN_WHITELIST=-100] autolearn=disabled Received: from mx1-lw-eu.apache.org ([10.40.0.8]) by localhost (spamd3-us-west.apache.org [10.40.0.10]) (amavisd-new, port 10024) with ESMTP id xFkV8n4ZZJ-k for ; Wed, 2 May 2018 01:22:07 +0000 (UTC) Received: from mailrelay1-us-west.apache.org (mailrelay1-us-west.apache.org [209.188.14.139]) by mx1-lw-eu.apache.org (ASF Mail Server at mx1-lw-eu.apache.org) with ESMTP id 9B9E35FB3B for ; Wed, 2 May 2018 01:22:06 +0000 (UTC) Received: from jira-lw-us.apache.org (unknown [207.244.88.139]) by mailrelay1-us-west.apache.org (ASF Mail Server at mailrelay1-us-west.apache.org) with ESMTP id C5A48E0181 for ; Wed, 2 May 2018 01:22:05 +0000 (UTC) Received: from jira-lw-us.apache.org (localhost [127.0.0.1]) by jira-lw-us.apache.org (ASF Mail Server at jira-lw-us.apache.org) with ESMTP id 3EB022129D for ; Wed, 2 May 2018 01:22:00 +0000 (UTC) Date: Wed, 2 May 2018 01:22:00 +0000 (UTC) From: "James Taylor (JIRA)" To: dev@phoenix.apache.org Message-ID: In-Reply-To: References: Subject: [jira] [Commented] (PHOENIX-4712) When creating an index on a table, meta data cache of views related to the table isn't updated MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 [ https://issues.apache.org/jira/browse/PHOENIX-4712?page=3Dcom.atlassi= an.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=3D16= 460368#comment-16460368 ]=20 James Taylor commented on PHOENIX-4712: --------------------------------------- So the check we have to only do the combining logic if the parent was updat= ed is flawed. Even with a separate connection, I can repro the issue by ref= erencing the table in a statement before executing a query on the view. Let's go with your version of the patch for 4.14. We can improve if need be= post splittable sys cat, either by doing the combining on the server or on= the client by storing=C2=A0the sequence number of the parent on the child,= and then combining if the sequence doesn't match. > When creating an index on a table, meta data cache of views related to th= e table isn't updated > -------------------------------------------------------------------------= --------------------- > > Key: PHOENIX-4712 > URL: https://issues.apache.org/jira/browse/PHOENIX-4712 > Project: Phoenix > Issue Type: Bug > Reporter: Toshihiro Suzuki > Assignee: Toshihiro Suzuki > Priority: Major > Attachments: PHOENIX-4712-v2.patch, PHOENIX-4712.patch, PHOENIX-4= 712.patch, PHOENIX-4712_v3.patch > > > Steps to reproduce are as follows: > 1. Create a table > {code} > create table tbl (col1 varchar primary key, col2 varchar); > {code} > 2. Create a view on the table > {code} > create view vw (col3 varchar) as select * from tbl; > {code} > 3. Create a index on the table > {code} > create index idx ON tbl (col2); > {code} > After those, when issuing a explain query like the following, it seems li= ke the query doesn't use the index, although the index should be used:=20 > {code} > 0: jdbc:phoenix:> explain select /*+ INDEX(vw idx) */ * from vw where col= 2 =3D 'aaa'; > +---------------------------------------------------------------+ > | PLAN | > +---------------------------------------------------------------+ > | CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER TBL | > | SERVER FILTER BY COL2 =3D 'aaa' | > +---------------------------------------------------------------+ > {code} > However, after restarting sqlline, the explain output is changed, and the= index is used. > {code} > 0: jdbc:phoenix:> explain select /*+ INDEX(vw idx) */ * from vw where col= 2 =3D 'aaa'; > +------------------------------------------------------------------------= --------+ > | PLAN = | > +------------------------------------------------------------------------= --------+ > | CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN FULL SCAN OVER TBL = | > | SKIP-SCAN-JOIN TABLE 0 = | > | CLIENT 1-CHUNK PARALLEL 1-WAY ROUND ROBIN RANGE SCAN OVER IDX [= 'aaa'] | > | SERVER FILTER BY FIRST KEY ONLY = | > | DYNAMIC SERVER FILTER BY "VW.COL1" IN ($3.$5) = | > +------------------------------------------------------------------------= --------+ > {code} > I think when creating an index on a table, meta data cache of views relat= ed to the table isn't updated, so the index isn't used for that query. Howe= ver after restarting sqlline, the meta data cache is refreshed, so the inde= x is used. > When creating an index on a table, we should update meta data cache of vi= ews related to the table. -- This message was sent by Atlassian JIRA (v7.6.3#76005)