1. 16 May, 2018 4 commits
    • Tom Lane's avatar
      Fix misprocessing of equivalence classes involving record_eq(). · a11b3bd3
      Tom Lane authored
      canonicalize_ec_expression() is supposed to agree with coerce_type() as to
      whether a RelabelType should be inserted to make a subexpression be valid
      input for the operators of a given opclass.  However, it did the wrong
      thing with named-composite-type inputs to record_eq(): it put in a
      RelabelType to RECORDOID, which the parser doesn't.  In some cases this was
      harmless because all code paths involving a particular equivalence class
      did the same thing, but in other cases this would result in failing to
      recognize a composite-type expression as being a member of an equivalence
      class that it actually is a member of.  The most obvious bad effect was to
      fail to recognize that an index on a composite column could provide the
      sort order needed for a mergejoin on that column, as reported by Teodor
      Sigaev.  I think there might be other, subtler, cases that result in
      misoptimization.  It also seems possible that an unwanted RelabelType
      would sometimes get into an emitted plan --- but because record_eq and
      friends don't examine the declared type of their input expressions, that
      would not create any visible problems.
      
      To fix, just treat RECORDOID as if it were a polymorphic type, which in
      some sense it is.  We might want to consider formalizing that a bit more
      someday, but for the moment this seems to be the only place where an
      IsPolymorphicType() test ought to include RECORDOID as well.
      
      This has been broken for a long time, so back-patch to all supported
      branches.
      
      Discussion: https://postgr.es/m/a6b22369-e3bf-4d49-f59d-0c41d3551e81@sigaev.ru
      a11b3bd3
    • Robert Haas's avatar
      Pass the correct PlannerInfo to PlanForeignModify/PlanDirectModify. · 7fc7dac1
      Robert Haas authored
      Previously, we passed the toplevel PlannerInfo, but we actually want
      to pass the relevant subroot.  One problem with passing the toplevel
      PlannerInfo is that the FDW which wants to push down an UPDATE or
      DELETE against a join won't find the relevant joinrel there.
      As of commit 1bc0100d, postgres_fdw
      tries to do exactly this and can be made to fail an assertion as a
      result.
      
      It's possible that this should be regarded as a bug fix and
      back-patched to earlier releases, but for lack of a test case that
      fails in earlier releases, no back-patch for now.
      
      Etsuro Fujita, reviewed by Amit Langote.
      
      Discussion: http://postgr.es/m/5AF43E02.30000@lab.ntt.co.jp
      7fc7dac1
    • Robert Haas's avatar
      Improve comment in get_partition_dispatch_recurse. · 09b12d52
      Robert Haas authored
      David Rowley, reviewed by Amit Langote, and revised a bit by me.
      
      Discussion: http://postgr.es/m/CAKJS1f9yyimYyFzbHM4EwE+tkj4jvrHqSH0H4S4Kbas=UFpc9Q@mail.gmail.com
      09b12d52
    • Bruce Momjian's avatar
      docs: add space in PG 11 release notes, huge/large · 6bd1b4c3
      Bruce Momjian authored
      Reported-by: Tatsuo Ishii
      6bd1b4c3
  2. 15 May, 2018 5 commits
  3. 14 May, 2018 5 commits
  4. 13 May, 2018 1 commit
  5. 12 May, 2018 1 commit
  6. 11 May, 2018 5 commits
  7. 10 May, 2018 1 commit
    • Teodor Sigaev's avatar
      Various improvements of skipping index scan during vacuum technics · 8e12f4a2
      Teodor Sigaev authored
      - Change vacuum_cleanup_index_scale_factor GUC to PGC_USERSET.
        vacuum_cleanup_index_scale_factor GUC was defined as PGC_SIGHUP.  But this
        GUC affects not only autovacuum.  So it might be useful to change it from user
        session in order to influence manually runned VACUUM.
      - Add missing tab-complete support for vacuum_cleanup_index_scale_factor
        reloption.
      - Fix condition for B-tree index cleanup.
        Zero value of vacuum_cleanup_index_scale_factor means that user wants B-tree
        index cleanup to be never skipped.
      - Documentation and comment improvements
      
      Authors: Justin Pryzby, Alexander Korotkov, Liudmila Mantrova
      Reviewed by: all authors and Robert Haas
      Discussion: https://www.postgresql.org/message-id/flat/20180502023025.GD7631%40telsasoft.com
      8e12f4a2
  8. 09 May, 2018 13 commits
  9. 08 May, 2018 3 commits
    • Tom Lane's avatar
      Improve initdb's query for generating default descriptions a little. · dec10340
      Tom Lane authored
      While poking into initdb's performance, I noticed that this query
      wasn't being done very intelligently.  By forcing it to execute
      obj_description() for each pg_proc/pg_operator join row, we were
      essentially setting up a nestloop join to pg_description, which
      is not a bright query plan when there are hundreds of outer rows.
      Convert the check for a "deprecated" operator into a NOT EXISTS
      so that it can be done as a hashed antijoin.  On my workstation
      this reduces the time for this query from ~ 35ms to ~ 10ms.
      Which is not a huge win, but it adds up over buildfarm runs.
      
      In passing, insert forced query breaks (\n\n, in single-user mode)
      after each SQL-query file that initdb sources, and after some
      relatively new queries in setup_privileges().  This doesn't make
      a lot of difference normally, but it will result in briefer, saner
      error messages if anything goes wrong.
      dec10340
    • Peter Eisentraut's avatar
      Refine error messages · 831f5d11
      Peter Eisentraut authored
      "JSON" when not referring to a data type should be upper case.
      831f5d11
    • Tom Lane's avatar
      Count heap tuples in non-SnapshotAny path in IndexBuildHeapRangeScan(). · 3a675f72
      Tom Lane authored
      Brown-paper-bag bug in commit 7c91a036: when we rearranged the placement
      of "reltuples += 1" statements, we missed including one in this code path.
      
      The net effect of that was that CREATE INDEX CONCURRENTLY would set the
      table's pg_class.reltuples to zero, as would index builds done during
      bootstrap mode.  (It seems like parallel index builds ought to fail
      similarly, but they don't, perhaps because reltuples is computed in some
      other way.  You certainly couldn't figure that out from the abysmally
      underdocumented parallelism code in this area.)
      
      I was led to this by wondering why initdb seemed to have slowed down as
      a result of 7c91a036, as is evident in the buildfarm's timing history.
      The reason is that every system catalog with indexes had pg_class.reltuples
      = 0 after bootstrap, causing the planner to make some terrible choices for
      queries in the post-bootstrap steps.  On my workstation, this fix causes
      the runtime of "initdb -N" to drop from ~2.0 sec to ~1.4 sec, which is
      almost though not quite back to where it was in v10.  That's not much of
      a deal for production use perhaps, but it makes a noticeable difference
      for buildfarm and "make check-world" runs, which do a lot of initdbs.
      3a675f72
  10. 07 May, 2018 2 commits
    • Andrew Dunstan's avatar
      Clean up some perlcritic warnings · d2c1512a
      Andrew Dunstan authored
      In Catalog.pm, mark eval of a string instead of a block as allowed.
      Disallow perlcritic completely in Gen_dummy_probes.pl, as it's
      generated code.
      Protect a couple of lines in plperl code from  perltidy, so that the
      annotation for perlcritic stays on the same line as the construct it
      would otherwise object to.
      d2c1512a
    • Tom Lane's avatar
      Undo extra chattiness of postmaster logs in TAP tests. · 17551f1a
      Tom Lane authored
      Commit 6271fceb changed PostgresNode.pm to force log_min_messages = debug1
      in all TAP tests, without any discussion and without a concrete need for
      it.  This makes some of the TAP tests noticeably slower (although much of
      that may be due to poorly-written regexes), and for certain it's bloating
      the buildfarm logs.  Revert the change.
      
      Discussion: https://postgr.es/m/32459.1525657786@sss.pgh.pa.us
      17551f1a