Skip to content
Snippets Groups Projects
  1. Mar 08, 2008
    • Tom Lane's avatar
      This patch addresses some issues in TOAST compression strategy that · ad434473
      Tom Lane authored
      were discussed last year, but we felt it was too late in the 8.3 cycle to
      change the code immediately.  Specifically, the patch:
      
      * Reduces the minimum datum size to be considered for compression from
      256 to 32 bytes, as suggested by Greg Stark.
      
      * Increases the required compression rate for compressed storage from
      20% to 25%, again per Greg's suggestion.
      
      * Replaces force_input_size (size above which compression is forced)
      with a maximum size to be considered for compression.  It was agreed
      that allowing large inputs to escape the minimum-compression-rate
      requirement was not bright, and that indeed we'd rather have a knob
      that acted in the other direction.  I set this value to 1MB for the
      moment, but it could use some performance studies to tune it.
      
      * Adds an early-failure path to the compressor as suggested by Jan:
      if it's been unable to find even one compressible substring in the
      first 1KB (parameterizable), assume we're looking at incompressible
      input and give up.  (Possibly this logic can be improved, but I'll
      commit it as-is for now.)
      
      * Improves the toasting heuristics so that when we have very large
      fields with attstorage 'x' or 'e', we will push those out to toast
      storage before considering inline compression of shorter fields.
      This also responds to a suggestion of Greg's, though my original
      proposal for a solution was a bit off base because it didn't fix
      the problem for large 'e' fields.
      
      There was some discussion in the earlier threads of exposing some
      of the compression knobs to users, perhaps even on a per-column
      basis.  I have not done anything about that here.  It seems to me
      that if we are changing around the parameters, we'd better get some
      experience and be sure we are happy with the design before we set
      things in stone by providing user-visible knobs.
      ad434473
  2. Mar 07, 2008
  3. Mar 06, 2008
  4. Mar 05, 2008
Loading