hive-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hive QA (Jira)" <>
Subject [jira] [Commented] (HIVE-22238) PK/FK selectivity estimation underscales estimations
Date Tue, 29 Oct 2019 14:59:00 GMT


Hive QA commented on HIVE-22238:

Here are the results of testing the latest attachment:

{color:green}SUCCESS:{color} +1 due to 4 test(s) being added or modified.

{color:red}ERROR:{color} -1 due to 1 failed/errored test(s), 17549 tests executed
*Failed tests:*
org.apache.hadoop.hive.ql.lockmgr.TestDbTxnManager2.insertOverwriteCreateAcid (batchId=353)

Test results:
Console output:
Test logs:

Executing org.apache.hive.ptest.execution.TestCheckPhase
Executing org.apache.hive.ptest.execution.PrepPhase
Executing org.apache.hive.ptest.execution.YetusPhase
Executing org.apache.hive.ptest.execution.ExecutionPhase
Executing org.apache.hive.ptest.execution.ReportingPhase
Tests exited with: TestsFailedException: 1 tests failed

This message is automatically generated.

ATTACHMENT ID: 12984247 - PreCommit-HIVE-Build

> PK/FK selectivity estimation underscales estimations
> ----------------------------------------------------
>                 Key: HIVE-22238
>                 URL:
>             Project: Hive
>          Issue Type: Bug
>          Components: Statistics
>            Reporter: Zoltan Haindrich
>            Assignee: Zoltan Haindrich
>            Priority: Major
>              Labels: pull-request-available
>         Attachments: HIVE-22238.01.patch, HIVE-22238.02.patch, HIVE-22238.03.patch, HIVE-22238.04.patch,
HIVE-22238.05.patch, HIVE-22238.05.patch
>          Time Spent: 10m
>  Remaining Estimate: 0h
> at [this point|]
the parent operators rownum is scaled according to pkfkselectivity
> however [pkfkselectivity is computed|]
on a whole subtree.
> Scaling it by that amount will count in estimation already used when parentstats was depending on the number of upstream joins - this may lead to severe underestimations
> what happened was:
> * optimization was able to push the filter to the other side of the join
> * as a result the incoming data was already filtered
> * scaling down by the PK selectiviy - was actually already there...but a new "scaling"

This message was sent by Atlassian Jira

View raw message