• Robert Haas's avatar
    Allow configurable LZ4 TOAST compression. · bbe0a81d
    Robert Haas authored
    There is now a per-column COMPRESSION option which can be set to pglz
    (the default, and the only option in up until now) or lz4. Or, if you
    like, you can set the new default_toast_compression GUC to lz4, and
    then that will be the default for new table columns for which no value
    is specified. We don't have lz4 support in the PostgreSQL code, so
    to use lz4 compression, PostgreSQL must be built --with-lz4.
    
    In general, TOAST compression means compression of individual column
    values, not the whole tuple, and those values can either be compressed
    inline within the tuple or compressed and then stored externally in
    the TOAST table, so those properties also apply to this feature.
    
    Prior to this commit, a TOAST pointer has two unused bits as part of
    the va_extsize field, and a compessed datum has two unused bits as
    part of the va_rawsize field. These bits are unused because the length
    of a varlena is limited to 1GB; we now use them to indicate the
    compression type that was used. This means we only have bit space for
    2 more built-in compresison types, but we could work around that
    problem, if necessary, by introducing a new vartag_external value for
    any further types we end up wanting to add. Hopefully, it won't be
    too important to offer a wide selection of algorithms here, since
    each one we add not only takes more coding but also adds a build
    dependency for every packager. Nevertheless, it seems worth doing
    at least this much, because LZ4 gets better compression than PGLZ
    with less CPU usage.
    
    It's possible for LZ4-compressed datums to leak into composite type
    values stored on disk, just as it is for PGLZ. It's also possible for
    LZ4-compressed attributes to be copied into a different table via SQL
    commands such as CREATE TABLE AS or INSERT .. SELECT.  It would be
    expensive to force such values to be decompressed, so PostgreSQL has
    never done so. For the same reasons, we also don't force recompression
    of already-compressed values even if the target table prefers a
    different compression method than was used for the source data.  These
    architectural decisions are perhaps arguable but revisiting them is
    well beyond the scope of what seemed possible to do as part of this
    project.  However, it's relatively cheap to recompress as part of
    VACUUM FULL or CLUSTER, so this commit adjusts those commands to do
    so, if the configured compression method of the table happens not to
    match what was used for some column value stored therein.
    
    Dilip Kumar. The original patches on which this work was based were
    written by Ildus Kurbangaliev, and those were patches were based on
    even earlier work by Nikita Glukhov, but the design has since changed
    very substantially, since allow a potentially large number of
    compression methods that could be added and dropped on a running
    system proved too problematic given some of the architectural issues
    mentioned above; the choice of which specific compression method to
    add first is now different; and a lot of the code has been heavily
    refactored.  More recently, Justin Przyby helped quite a bit with
    testing and reviewing and this version also includes some code
    contributions from him. Other design input and review from Tomas
    Vondra, Álvaro Herrera, Andres Freund, Oleg Bartunov, Alexander
    Korotkov, and me.
    
    Discussion: http://postgr.es/m/20170907194236.4cefce96%40wp.localdomain
    Discussion: http://postgr.es/m/CAFiTN-uUpX3ck%3DK0mLEk-G_kUQY%3DSNOTeqdaNRR9FMdQrHKebw%40mail.gmail.com
    bbe0a81d
configure.ac 81.3 KB