1. 03 Apr, 2019 17 commits
  2. 31 Mar, 2019 5 commits
  3. 30 Mar, 2019 7 commits
    • Tom Lane's avatar
      Speed up planning when partitions can be pruned at plan time. · 428b260f
      Tom Lane authored
      Previously, the planner created RangeTblEntry and RelOptInfo structs
      for every partition of a partitioned table, even though many of them
      might later be deemed uninteresting thanks to partition pruning logic.
      This incurred significant overhead when there are many partitions.
      Arrange to postpone creation of these data structures until after
      we've processed the query enough to identify restriction quals for
      the partitioned table, and then apply partition pruning before not
      after creation of each partition's data structures.  In this way
      we need not open the partition relations at all for partitions that
      the planner has no real interest in.
      For queries that can be proven at plan time to access only a small
      number of partitions, this patch improves the practical maximum
      number of partitions from under 100 to perhaps a few thousand.
      Amit Langote, reviewed at various times by Dilip Kumar, Jesper Pedersen,
      Yoshikazu Imai, and David Rowley
      Discussion: https://postgr.es/m/9d7c5112-cb99-6a47-d3be-cf1ee6862a1d@lab.ntt.co.jp
    • Tomas Vondra's avatar
      Fix compiler warnings in multivariate MCV code · ad3107b9
      Tomas Vondra authored
      Compiler warnings were observed on gcc 3.4.6 (on gaur).
      The assert is unnecessary, as the indexes are uint16 and so always >= 0.
      Reported-by: Tom Lane
    • Tomas Vondra's avatar
      Additional fixes of memory alignment in pg_mcv_list code · ea4e1c0e
      Tomas Vondra authored
      Commit d85e0f36 tried to fix memory alignment issues in serialization
      and deserialization of pg_mcv_list values, but it was a few bricks shy.
      The arrays of uint16 indexes in serialized items was not aligned, and
      the both the values and isnull flags were using the same pointer.
      Per investigation by Tom Lane on gaur.
    • Tom Lane's avatar
      Avoid crash in partitionwise join planning under GEQO. · 7ad6498f
      Tom Lane authored
      While trying to plan a partitionwise join, we may be faced with cases
      where one or both input partitions for a particular segment of the join
      have been pruned away.  In HEAD and v11, this is problematic because
      earlier processing didn't bother to make a pruned RelOptInfo fully
      valid.  With an upcoming patch to make partition pruning more efficient,
      this'll be even more problematic because said RelOptInfo won't exist at
      The existing code attempts to deal with this by retroactively making the
      RelOptInfo fully valid, but that causes crashes under GEQO because join
      planning is done in a short-lived memory context.  In v11 we could
      probably have fixed this by switching to the planner's main context
      while fixing up the RelOptInfo, but that idea doesn't scale well to the
      upcoming patch.  It would be better not to mess with the base-relation
      data structures during join planning, anyway --- that's just a recipe
      for order-of-operations bugs.
      In many cases, though, we don't actually need the child RelOptInfo,
      because if the input is certainly empty then the join segment's result
      is certainly empty, so we can skip making a join plan altogether.  (The
      existing code ultimately arrives at the same conclusion, but only after
      doing a lot more work.)  This approach works except when the pruned-away
      partition is on the nullable side of a LEFT, ANTI, or FULL join, and the
      other side isn't pruned.  But in those cases the existing code leaves a
      lot to be desired anyway --- the correct output is just the result of
      the unpruned side of the join, but we were emitting a useless outer join
      against a dummy Result.  Pending somebody writing code to handle that
      more nicely, let's just abandon the partitionwise-join optimization in
      such cases.
      When the modified code skips making a join plan, it doesn't make a
      join RelOptInfo either; this requires some upper-level code to
      cope with nulls in part_rels[] arrays.  We would have had to have
      that anyway after the upcoming patch.
      Back-patch to v11 since the crash is demonstrable there.
      Discussion: https://postgr.es/m/8305.1553884377@sss.pgh.pa.us
    • Peter Eisentraut's avatar
      doc: Fix typo · ef6576f5
      Peter Eisentraut authored
      Author: Justin Pryzby <pryzby@telsasoft.com>
    • Peter Eisentraut's avatar
      Generated columns · fc22b662
      Peter Eisentraut authored
      This is an SQL-standard feature that allows creating columns that are
      computed from expressions rather than assigned, similar to a view or
      materialized view but on a column basis.
      This implements one kind of generated column: stored (computed on
      write).  Another kind, virtual (computed on read), is planned for the
      future, and some room is left for it.
      Reviewed-by: default avatarMichael Paquier <michael@paquier.xyz>
      Reviewed-by: default avatarPavel Stehule <pavel.stehule@gmail.com>
      Discussion: https://www.postgresql.org/message-id/flat/b151f851-4019-bdb1-699e-ebab07d2f40a@2ndquadrant.com
    • Peter Eisentraut's avatar
      Small code simplification for REINDEX CONCURRENTLY · 6b8b5364
      Peter Eisentraut authored
      This was left over from an earlier code structure.
  4. 29 Mar, 2019 11 commits