phoenix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Samarth Jain (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (PHOENIX-2724) Query with large number of guideposts is slower compared to no stats
Date Thu, 21 Apr 2016 17:12:26 GMT

     [ https://issues.apache.org/jira/browse/PHOENIX-2724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Samarth Jain updated PHOENIX-2724:
----------------------------------
    Attachment: PHOENIX-2724_v2.patch

Thanks for the review [~jamestaylor] and [~ankit.singhal].

We can't use SerialIterators any more if the tables are salted or local indexes and a row
key order is requested. This is because we need to be able to do a merge sort between all
the scanners which isn't possible now when we are using SerialIterators.

This also brings up an interesting question - what should we do if the user has explicitly
requested serial execution via a hint. In the above case, serial execution will return wrong
results. Maybe we should throw an error or probably just log a warning? After all it is just
a hint and it is up to the query engine to decide whether or not to honor it?

[~ankit.singhal] - Good catch on the table name in the log line in SerialIterators.java. I
have fixed it. I moved the helper methods in QueryWithOffsetIT towards the end of the file
as it made it convenient to comment tests out.

> Query with large number of guideposts is slower compared to no stats
> --------------------------------------------------------------------
>
>                 Key: PHOENIX-2724
>                 URL: https://issues.apache.org/jira/browse/PHOENIX-2724
>             Project: Phoenix
>          Issue Type: Bug
>    Affects Versions: 4.7.0
>         Environment: Phoenix 4.7.0-RC4, HBase-0.98.17 on a 8 node cluster
>            Reporter: Mujtaba Chohan
>            Assignee: Samarth Jain
>             Fix For: 4.8.0
>
>         Attachments: PHOENIX-2724.patch, PHOENIX-2724_v2.patch
>
>
> With 1MB guidepost width for ~900GB/500M rows table. Queries with short scan range gets
significantly slower.
> Without stats:
> {code}
> select * from T limit 10; // query execution time <100 msec
> {code}
> With stats:
> {code}
> select * from T limit 10; // query execution time >20 seconds
> Explain plan: CLIENT 876085-CHUNK 476569382 ROWS 876060986727 BYTES SERIAL 1-WAY FULL
SCAN OVER T SERVER 10 ROW LIMIT CLIENT 10 ROW LIMIT
> {code}



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

Mime
View raw message