Skip to content

P
Postgres FD Implementation
Switch branch/tag
  1. 01 Oct, 2019 1 commit
    • Tomas Vondra's avatar
      Add transparent block-level memory accounting · 5dd7fc15
      Tomas Vondra authored 
      Adds accounting of memory allocated in a memory context. Compared to
various ad hoc solutions, the main advantage is that the accounting is
transparent and does not require direct control over allocations (this
matters for use cases where the allocations happen in user code, like
for example aggregate states allocated in a transition functions).

To reduce overhead, the accounting happens at the block level (not for
individual chunks) and only the context immediately owning the block is
updated. When inquiring about amount of memory allocated in a context,
we have to recursively walk all children contexts.

This "lazy" accounting works well for cases with relatively small number
of contexts in the relevant subtree and/or with infrequent inquiries.

Author: Jeff Davis
Reivewed-by: Tomas Vondra, Melanie Plageman, Soumyadeep Chakraborty
Discussion: https://www.postgresql.org/message-id/flat/027a129b8525601c6a680d27ce3a7172dab61aab.camel@j-davis.com
      5dd7fc15
  3. 30 Sep, 2019 11 commits
  5. 29 Sep, 2019 6 commits
    • Andres Freund's avatar
      jit: Re-allow JIT compilation of execGrouping.c hashtable comparisons. · ac88807f
      Andres Freund authored 
      In the course of 5567d12c, 356687bd and 317ffdfe, I changed
BuildTupleHashTable[Ext]'s call to ExecBuildGroupingEqual to not pass
in the parent node, but NULL. Which in turn prevents the tuple
equality comparator from being JIT compiled.  While that fixes
bug #15486, it is not actually necessary after all of the above commits,
as we don't re-build the comparator when using the new
BuildTupleHashTableExt() interface (as the content of the hashtable
are reset, but the TupleHashTable itself is not).

Therefore re-allow jit compilation for callers that use
BuildTupleHashTableExt with a separate context for "metadata" and
content.

As in the previous commit, there's ongoing work to make this easier to
test to prevent such regressions in the future, but that
infrastructure is not going to be backpatchable.

The performance impact of not JIT compiling hashtable equality
comparators can be substantial e.g. for aggregation queries that
aggregate a lot of input rows to few output rows (when there are a lot
of output groups, there will be fewer comparisons).

Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 11, just as 5567d12c
      ac88807f
    • Andres Freund's avatar
      Fix determination when slot types for upper executor nodes are fixed. · 97e971ee
      Andres Freund authored 
      For many queries the fact that the tuple descriptor from the lower
node was not taken into account when determining whether the type of a
slot is fixed, lead to tuple deforming for such upper nodes not to be
JIT accelerated.

I broke this in 675af5c0.

There is ongoing work to enable writing regression tests for related
behavior (including a patch that would have detected this
regression), by optionally showing such details in EXPLAIN. But as it
seems unlikely that that will be suitable for stable branches, just
merge the fix for now.

While it's fairly close to the 12 release window, the fact that 11
continues to perform JITed tuple deforming in these cases, that
there's still cases where we do so in 12, and the fact that the
performance regression can be sizable, weigh in favor of fixing it
now.

Author: Andres Freund
Discussion: https://postgr.es/m/20190927072053.njf6prdl3vb7y7qb@alap3.anarazel.de
Backpatch: 12-, where 675af5c0 was merged.
      97e971ee
    • Andrew Dunstan's avatar
      Allow SSL TAP tests to run on Windows · 258bf86a
      Andrew Dunstan authored 
      Windows does not enforce key file permissions checks in libpq, and psql
can produce CRLF line endings on Windows.

Backpatch to Release 12 (CRLF) and Release 11 (permissions check)
      258bf86a
    • Peter Eisentraut's avatar
      doc: Further clarify how recovery target parameters are applied · e04a53a6
      Peter Eisentraut authored 
      Recovery target parameters are all applied even in standby mode.  The
previous documentation mostly wished they were not but this was never
the case.

Discussion: https://www.postgresql.org/message-id/flat/e445616d-023e-a268-8aa1-67b8b335340c%40pgmasters.net
      e04a53a6
    • Tom Lane's avatar
      Fix bogus order of error checks in new channel_binding code. · 2c97f734
      Tom Lane authored 
      Coverity pointed out that it's pretty silly to check for a null pointer
after we've already dereferenced the pointer.  To fix, just swap the
order of the two error checks.  Oversight in commit d6e612f8.
      2c97f734
    • Peter Eisentraut's avatar
      doc: Add a link target · 92f1545d
      Peter Eisentraut authored 
      Forward-patched from PostgreSQL 12 release notes patch, for
consistency.
      92f1545d
  7. 28 Sep, 2019 3 commits
  9. 27 Sep, 2019 11 commits
  11. 26 Sep, 2019 6 commits
  13. 25 Sep, 2019 2 commits