← Back to branch summary

~ubuntu-branches/ubuntu/trusty/postgresql-9.3/trusty-proposed

« back to all changes in this revision

Viewing changes to src/backend/optimizer/util/pathnode.c

  • Committer: Package Import Robot
  • Author(s): Martin Pitt
  • Date: 2014-07-24 16:13:59 UTC
  • mfrom: (1.1.8)
  • Revision ID: package-import@ubuntu.com-20140724161359-uk325qfv03euxuuh
Tags: 9.3.5-0ubuntu0.14.04.1
https://launchpad.net/bugs/1348176
* New upstream bug fix release: (LP: #1348176)
  - pg_upgrade: Users who upgraded to version 9.3 using pg_upgrade may have
    an issue with transaction information which causes VACUUM to eventually
    fail. These users should run the script provided in the release notes to
    determine if their installation is affected, and then take the remedy
    steps outlined there.
  - Various data integrity and other bug fixes.
  - Secure Unix-domain sockets of temporary postmasters started during make
    check.
    Any local user able to access the socket file could connect as the
    server's bootstrap superuser, then proceed to execute arbitrary code as
    the operating-system user running the test, as we previously noted in
    CVE-2014-0067. This change defends against that risk by placing the
    server's socket in a temporary, mode 0700 subdirectory of /tmp.
  - See release notes for details:
    http://www.postgresql.org/about/news/1534/
* Remove pg_regress patches to support --host=/path, obsolete with above
  upstream changes and not applicable any more.
* Drop tcl8.6 patch, applied upstream.
* Add missing logrotate test dependency.

Show diffs side-by-side

added added

removed removed

Lines of Context:
src/backend/optimizer/util/pathnode.c
127
127
 *
128
128
 * The fuzz_factor argument must be 1.0 plus delta, where delta is the
129
129
 * fraction of the smaller cost that is considered to be a significant
130
 
 * difference.  For example, fuzz_factor = 1.01 makes the fuzziness limit
 
130
 * difference.  For example, fuzz_factor = 1.01 makes the fuzziness limit
131
131
 * be 1% of the smaller cost.
132
132
 *
133
133
 * The two paths are said to have "equal" costs if both startup and total
134
 
 * costs are fuzzily the same.  Path1 is said to be better than path2 if
 
134
 * costs are fuzzily the same.  Path1 is said to be better than path2 if
135
135
 * it has fuzzily better startup cost and fuzzily no worse total cost,
136
136
 * or if it has fuzzily better total cost and fuzzily no worse startup cost.
137
137
 * Path2 is better than path1 if the reverse holds.  Finally, if one path
207
207
 *
208
208
 * cheapest_total_path is normally the cheapest-total-cost unparameterized
209
209
 * path; but if there are no unparameterized paths, we assign it to be the
210
 
 * best (cheapest least-parameterized) parameterized path.      However, only
 
210
 * best (cheapest least-parameterized) parameterized path.  However, only
211
211
 * unparameterized paths are considered candidates for cheapest_startup_path,
212
212
 * so that will be NULL if there are no unparameterized paths.
213
213
 *
214
214
 * The cheapest_parameterized_paths list collects all parameterized paths
215
 
 * that have survived the add_path() tournament for this relation.      (Since
 
215
 * that have survived the add_path() tournament for this relation.  (Since
216
216
 * add_path ignores pathkeys and startup cost for a parameterized path,
217
217
 * these will be paths that have best total cost or best row count for their
218
218
 * parameterization.)  cheapest_parameterized_paths always includes the
431
431
                p1_next = lnext(p1);
432
432
 
433
433
                /*
434
 
                 * Do a fuzzy cost comparison with 1% fuzziness limit.  (XXX does this
 
434
                 * Do a fuzzy cost comparison with 1% fuzziness limit.  (XXX does this
435
435
                 * percentage need to be user-configurable?)
436
436
                 */
437
437
                costcmp = compare_path_costs_fuzzily(new_path, old_path, 1.01,
607
607
 *        and have lower bounds for its costs.
608
608
 *
609
609
 * Note that we do not know the path's rowcount, since getting an estimate for
610
 
 * that is too expensive to do before prechecking.      We assume here that paths
 
610
 * that is too expensive to do before prechecking.  We assume here that paths
611
611
 * of a superset parameterization will generate fewer rows; if that holds,
612
612
 * then paths with different parameterizations cannot dominate each other
613
613
 * and so we can simply ignore existing paths of another parameterization.
907
907
         * Compute rows and costs as sums of subplan rows and costs.  We charge
908
908
         * nothing extra for the Append itself, which perhaps is too optimistic,
909
909
         * but since it doesn't do any selection or projection, it is a pretty
910
 
         * cheap node.  If you change this, see also make_append().
 
910
         * cheap node.  If you change this, see also make_append().
911
911
         */
912
912
        pathnode->path.rows = 0;
913
913
        pathnode->path.startup_cost = 0;
1456
1456
 *
1457
1457
 * colnos is an integer list of output column numbers (resno's).  We are
1458
1458
 * interested in whether rows consisting of just these columns are certain
1459
 
 * to be distinct.      "Distinctness" is defined according to whether the
 
1459
 * to be distinct.  "Distinctness" is defined according to whether the
1460
1460
 * corresponding upper-level equality operators listed in opids would think
1461
1461
 * the values are distinct.  (Note: the opids entries could be cross-type
1462
1462
 * operators, and thus not exactly the equality operators that the subquery
1474
1474
        Assert(list_length(colnos) == list_length(opids));
1475
1475
 
1476
1476
        /*
 
1477
         * A set-returning function in the query's targetlist can result in
 
1478
         * returning duplicate rows, if the SRF is evaluated after the
 
1479
         * de-duplication step; so we play it safe and say "no" if there are any
 
1480
         * SRFs.  (We could be certain that it's okay if SRFs appear only in the
 
1481
         * specified columns, since those must be evaluated before de-duplication;
 
1482
         * but it doesn't presently seem worth the complication to check that.)
 
1483
         */
 
1484
        if (expression_returns_set((Node *) query->targetList))
 
1485
                return false;
 
1486
 
 
1487
        /*
1477
1488
         * DISTINCT (including DISTINCT ON) guarantees uniqueness if all the
1478
1489
         * columns in the DISTINCT clause appear in colnos and operator semantics
1479
1490
         * match.
1577
1588
 * distinct_col_search - subroutine for query_is_distinct_for
1578
1589
 *
1579
1590
 * If colno is in colnos, return the corresponding element of opids,
1580
 
 * else return InvalidOid.      (We expect colnos does not contain duplicates,
 
1591
 * else return InvalidOid.  (We expect colnos does not contain duplicates,
1581
1592
 * so the result is well-defined.)
1582
1593
 */
1583
1594
static Oid
1977
1988
 
1978
1989
        /*
1979
1990
         * A hashjoin never has pathkeys, since its output ordering is
1980
 
         * unpredictable due to possible batching.      XXX If the inner relation is
 
1991
         * unpredictable due to possible batching.  XXX If the inner relation is
1981
1992
         * small enough, we could instruct the executor that it must not batch,
1982
1993
         * and then we could assume that the output inherits the outer relation's
1983
 
         * ordering, which might save a sort step.      However there is considerable
 
1994
         * ordering, which might save a sort step.  However there is considerable
1984
1995
         * downside if our estimate of the inner relation size is badly off. For
1985
1996
         * the moment we don't risk it.  (Note also that if we wanted to take this
1986
1997
         * seriously, joinpath.c would have to consider many more paths for the
2007
2018
 * same parameterization level, ensuring that they all enforce the same set
2008
2019
 * of join quals (and thus that that parameterization can be attributed to
2009
2020
 * an append path built from such paths).  Currently, only a few path types
2010
 
 * are supported here, though more could be added at need.      We return NULL
 
2021
 * are supported here, though more could be added at need.  We return NULL
2011
2022
 * if we can't reparameterize the given path.
2012
2023
 *
2013
2024
 * Note: we intentionally do not pass created paths to add_path(); it would
2039
2050
                                /*
2040
2051
                                 * We can't use create_index_path directly, and would not want
2041
2052
                                 * to because it would re-compute the indexqual conditions
2042
 
                                 * which is wasted effort.      Instead we hack things a bit:
 
2053
                                 * which is wasted effort.  Instead we hack things a bit:
2043
2054
                                 * flat-copy the path node, revise its param_info, and redo
2044
2055
                                 * the cost estimate.
2045
2056
                                 */