Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 11 May, 2018 5 commits
  3. 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
  5. 09 May, 2018 13 commits
  7. 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
  9. 07 May, 2018 11 commits
  11. 06 May, 2018 2 commits
  13. 05 May, 2018 4 commits
    • Tom Lane's avatar
      Fix bootstrap parser so that its keywords are unreserved words. · d160882a
      Tom Lane authored 
      Mark Dilger pointed out that the bootstrap parser does not allow
any of its keywords to appear as column values unless they're quoted,
and proposed dealing with that by quoting such values in genbki.pl.
Looking closer, though, we also have that problem with respect to table,
column, and type names appearing in the .bki file: the parser would fail
if any of those matched any of its keywords.  While so far there have
been no conflicts (that I've heard of), this seems like a booby trap
waiting to catch somebody.  Rather than clutter genbki.pl with enough
quoting logic to handle all that, let's make the bootstrap parser grow
up a little bit and treat its keywords as unreserved.

Experimentation shows that it's fairly easy to do so with the exception
of _null_, which I don't have a big problem with keeping as a reserved
word.  The only change needed is that we can't have the "close" command
take an optional table name: it has to either require or forbid the
table name to avoid shift/reduce conflicts.  genbki.pl has historically
always included the table name, so I took that option.

The implementation has bootscanner.l passing forward the string value
of each keyword, in case bootparse.y needs that.  This avoids needing to
know the precise spelling of each keyword in bootparse.y, which is good
because that's not always obvious from the token name.

Discussion: https://postgr.es/m/3024FC91-DB6D-4732-B31C-DF772DF039A0@gmail.com
      d160882a
    • Tom Lane's avatar
      Revert "Test conversion of NaN between float4 and float8." · 5c4c771d
      Tom Lane authored 
      This reverts commit 55e0e458.
It's served its purpose of demonstrating what was wrong on
buildfarm member opossum.  We could consider putting some kind
of single-purpose hack into ftod() to make the test pass there;
but I don't think it's worth the trouble, since there are surely
many other places whether this platform bug could manifest.
      5c4c771d
    • Tom Lane's avatar
      Put in_range_float4_float8's work in-line. · cb3e9e40
      Tom Lane authored 
      In commit 8b29e88c, I'd dithered about whether to make
in_range_float4_float8 be a standalone copy of the float in-range logic
or have it punt to in_range_float8_float8.  I went with the latter, which
saves code space though at the cost of performance and readability.

However, it emerges that this tickles a compiler or hardware bug on
buildfarm member opossum.  Test results from commit 55e0e458 show
conclusively that widening a float4 NaN to float8 produces Inf, not NaN,
on that machine; which accounts perfectly for the window RANGE test
failures it's been showing.  We can dodge this problem by making
in_range_float4_float8 be an independent function, so that it checks
for NaN inputs before widening them.

Ordinarily I'd not be very excited about working around such obviously
broken functionality; but given that this was a judgment call to begin
with, I don't mind reversing it.
      cb3e9e40
    • Peter Eisentraut's avatar
      Remove extra newlines after PQerrorMessage() · 2f525187
      Peter Eisentraut authored
      2f525187
  15. 04 May, 2018 1 commit
    • Tom Lane's avatar
      First-draft release notes for 10.4. · 488ccfe4
      Tom Lane authored 
      As usual, the release notes for other branches will be made by cutting
these down, but put them up for community review first.
      488ccfe4