Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Sat, 1 Jul 2017 21:27:00 +0000 (UTC)
From: "Bryan Pendleton (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.13082213.1498245436000.153717.1498944420067@Atlassian.JIRA>
In-Reply-To: <JIRA.13082213.1498245436000@Atlassian.JIRA>
References: <JIRA.13082213.1498245436000@Atlassian.JIRA> <JIRA.13082213.1498245436574@jira-lw-us.apache.org>
Subject: [jira] [Commented] (DERBY-6942) Utilise additional statistics for
 selectivity estimates.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 01 Jul 2017 21:27:04 -0000


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

Bryan Pendleton commented on DERBY-6942:
----------------------------------------

Let me see if I get that, too: the cost of the table scan is the same in either case, because we have to read every page of the table and evaluate the predicate against each row.

However, the number of rows in the result depends very heavily on the accuracy of the selectivity estimate. So if the results of the table scan go on to be used in a join with some other table, then the cost of the join will depend on the number of rows we read from the base table, and we can now have a more accurate estimate of that.

> Utilise additional statistics for selectivity estimates.
> --------------------------------------------------------
>
>                 Key: DERBY-6942
>                 URL: https://issues.apache.org/jira/browse/DERBY-6942
>             Project: Derby
>          Issue Type: Sub-task
>          Components: SQL
>            Reporter: Harshvardhan Gupta
>            Assignee: Harshvardhan Gupta
>            Priority: Minor
>         Attachments: DERBY-6942.diff, z12.txt, z13.txt
>
>


--
This message was sent by Atlassian JIRA
(v6.4.14#64029)