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
    has a small maxBlockSize: the maximum request size that we will treat as a
    "chunk" needs to be limited to fit in maxBlockSize.  Otherwise we will round
    up the request size to the next power of 2, wasting space, which is a bit
    pointless if we aren't going to make the blocks big enough to fit additional
    stuff in them.  The example motivating this is local buffer management, which
    makes repeated allocations of 8K (one BLCKSZ buffer) in TopMemoryContext,
    which has maxBlockSize = 8K because for the most part allocations there are
    small.  This leads to each local buffer actually eating 16K of space, which
    adds up when there are thousands of them.  I intend to change localbuf.c to
    aggregate its requests, which will prevent this particular misbehavior, but
    it seems likely that similar scenarios could arise elsewhere, so fixing the
    core problem seems wise as well.
    c22dea89
    History
    Name Last commit Last update