Skip to content
Snippets Groups Projects
Select Git revision
  • benchmark-tools
  • postgres-lambda
  • master default
  • REL9_4_25
  • REL9_5_20
  • REL9_6_16
  • REL_10_11
  • REL_11_6
  • REL_12_1
  • REL_12_0
  • REL_12_RC1
  • REL_12_BETA4
  • REL9_4_24
  • REL9_5_19
  • REL9_6_15
  • REL_10_10
  • REL_11_5
  • REL_12_BETA3
  • REL9_4_23
  • REL9_5_18
  • REL9_6_14
  • REL_10_9
  • REL_11_4
23 results

postgres-lambda-diff

  • Clone with SSH
  • Clone with HTTPS
  • user avatar
    Tom Lane authored
    I've been saying we needed to do this for more than five years, and here it
    finally is.  This patch removes the ever-growing tangle of spaghetti logic
    that grouping_planner() used to use to try to identify the best plan for
    post-scan/join query steps.  Now, there is (nearly) independent
    consideration of each execution step, and entirely separate construction of
    Paths to represent each of the possible ways to do that step.  We choose
    the best Path or set of Paths using the same add_path() logic that's been
    used inside query_planner() for years.
    
    In addition, this patch removes the old restriction that subquery_planner()
    could return only a single Plan.  It now returns a RelOptInfo containing a
    set of Paths, just as query_planner() does, and the parent query level can
    use each of those Paths as the basis of a SubqueryScanPath at its level.
    This allows finding some optimizations that we missed before, wherein a
    subquery was capable of returning presorted data and thereby avoiding a
    sort in the parent level, making the overall cost cheaper even though
    delivering sorted output was not the cheapest plan for the subquery in
    isolation.  (A couple of regression test outputs change in consequence of
    that.  However, there is very little change in visible planner behavior
    overall, because the point of this patch is not to get immediate planning
    benefits but to create the infrastructure for future improvements.)
    
    There is a great deal left to do here.  This patch unblocks a lot of
    planner work that was basically impractical in the old code structure,
    such as allowing FDWs to implement remote aggregation, or rewriting
    plan_set_operations() to allow consideration of multiple implementation
    orders for set operations.  (The latter will likely require a full
    rewrite of plan_set_operations(); what I've done here is only to fix it
    to return Paths not Plans.)  I have also left unfinished some localized
    refactoring in createplan.c and planner.c, because it was not necessary
    to get this patch to a working state.
    
    Thanks to Robert Haas, David Rowley, and Amit Kapila for review.
    3fc6e2d7
    History
    PostgreSQL Database Management System
    =====================================
    
    This directory contains the source code distribution of the PostgreSQL
    database management system.
    
    PostgreSQL is an advanced object-relational database management system
    that supports an extended subset of the SQL standard, including
    transactions, foreign keys, subqueries, triggers, user-defined types
    and functions.  This distribution also contains C language bindings.
    
    PostgreSQL has many language interfaces, many of which are listed here:
    
    	http://www.postgresql.org/download
    
    See the file INSTALL for instructions on how to build and install
    PostgreSQL.  That file also lists supported operating systems and
    hardware platforms and contains information regarding any other
    software packages that are required to build or run the PostgreSQL
    system.  Copyright and license information can be found in the
    file COPYRIGHT.  A comprehensive documentation set is included in this
    distribution; it can be read as described in the installation
    instructions.
    
    The latest version of this software may be obtained at
    http://www.postgresql.org/download/.  For more information look at our
    web site located at http://www.postgresql.org/.