Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pzbF2-000076-9t for pgsql-hackers@arkaria.postgresql.org; Thu, 18 May 2023 10:52:16 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1pzbF1-0007rN-3f for pgsql-hackers@arkaria.postgresql.org; Thu, 18 May 2023 10:52:15 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pzbF0-0007nd-PB for pgsql-hackers@lists.postgresql.org; Thu, 18 May 2023 10:52:14 +0000 Received: from mail-pf1-x42d.google.com ([2607:f8b0:4864:20::42d]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1pzbEx-000WH9-39 for pgsql-hackers@lists.postgresql.org; Thu, 18 May 2023 10:52:14 +0000 Received: by mail-pf1-x42d.google.com with SMTP id d2e1a72fcca58-64d1d68b4dbso518658b3a.3 for ; Thu, 18 May 2023 03:52:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=timescale.com; s=google; t=1684407130; x=1686999130; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=h/IKkq2wf+cW092nCQRh3XRmtXaoeWIp/RbfiM1yGUw=; b=ZK4+lyQk6TjJW9D+bA/R7XSo3bHBaYyUG6tLkEHdzdhtY+qBjmHPHaxnULOjqtlY/x kuGAvoprAiE3A6FgPL0mSkRYtJ35mWSsLpkKclMyUKnWYvi94UR68IpNXU6JqWBacCX2 g4GezJwhxWJ0qnEMPUvLkwzWhq9AvRMyN1ycMgPQxw96BR1cXDjoqY343+Dm3CavnAF6 g7QD5rzLGlN/9+cX0++U9q0EleKLvUI+Bujpfby0BX8vyCM4qenyt/aEjaNbFwEhlq7d K2aJrdFUy3k8GqAx9qVlql7TwPjlDlD0yrxeUxqqfnXv3cDFVtwyPprs9tRYyZPcSGYn yh1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1684407130; x=1686999130; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=h/IKkq2wf+cW092nCQRh3XRmtXaoeWIp/RbfiM1yGUw=; b=j/Q68bkwQ/6Otp3vZ2np5K6rFY9n8/HvOt4QmHz/xvfE5zoHsO7PcLt8ETeULCrX0B njfBnvhyusf6KT4s7Jid8Oy1c7QHX1y+vMhVqCRablHL5M7cL7TAt3Oi6pn6HVspey/b VnXHQMmGn7dWzaPA25ILEEqVSwV6zQkdzUDYJHvnhq1oaMSoS0/M0NTD0dVZYY1slvqJ KjkNsFrPzYCWClC/J7H0eV3t37vfvjFND9GcvUZSIoU88yZN++uALbZfo3Zt/C++XBVs +bKje23AJylCpVKnKjYZyKZC6bKahgjC9ipso6eTx05IAbUDJOvYXTOiYOBT7cSKITnY FA3A== X-Gm-Message-State: AC+VfDxp6p8hayxax2RouXbyuqc3meTKCpQtpx8Nlc9ujE+laMOtLcAR fAzsRc3NDS3+rKWFykh6rngBD5r0OEsHA0SSNf3UcvXWfHFFkVYlkG0= X-Google-Smtp-Source: ACHHUZ4YvA3PcopNbiOe6h0k3HN2XoWoiIfkiBcfezbx1jGeXqri0vxA4kVAjpFRzttJFb9SHpNLpePSiV1Y5JEJFlM= X-Received: by 2002:a05:6a21:7891:b0:100:607:b986 with SMTP id bf17-20020a056a21789100b001000607b986mr1625291pzc.56.1684407129825; Thu, 18 May 2023 03:52:09 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Aleksander Alekseev Date: Thu, 18 May 2023 13:51:58 +0300 Message-ID: Subject: Re: RFI: Extending the TOAST Pointer To: PostgreSQL Hackers Cc: Nikita Malakhov Content-Type: text/plain; charset="UTF-8" List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Hi Nikita, > this part of the PostgreSQL screams to be revised and improved I completely agree. The problem with TOAST pointers is that they are not extendable at the moment which prevents adding new compression algorithms (e.g. ZSTD), new features like compression dictionaries [1], etc. I suggest we add extensibility in order to solve this problem for the foreseeable future for everyone. > where Custom TOAST Pointer is distinguished from Regular one by va_flag field > which is a part of varlena header I don't think that varlena header is the best place to distinguish a classical TOAST pointer from an extended one. On top of that I don't see any free bits that would allow adding such a flag to the on-disk varlena representation [2]. The current on-disk TOAST pointer representation is following: ``` typedef struct varatt_external { int32 va_rawsize; /* Original data size (includes header) */ uint32 va_extinfo; /* External saved size (without header) and * compression method */ Oid va_valueid; /* Unique ID of value within TOAST table */ Oid va_toastrelid; /* RelID of TOAST table containing it */ } varatt_external; ``` Note that currently only 2 compression methods are supported: ``` typedef enum ToastCompressionId { TOAST_PGLZ_COMPRESSION_ID = 0, TOAST_LZ4_COMPRESSION_ID = 1, TOAST_INVALID_COMPRESSION_ID = 2 } ToastCompressionId; ``` I suggest adding a new flag that will mark an extended TOAST format: ``` typedef enum ToastCompressionId { TOAST_PGLZ_COMPRESSION_ID = 0, TOAST_LZ4_COMPRESSION_ID = 1, TOAST_RESERVED_COMPRESSION_ID = 2, TOAST_HAS_EXTENDED_FORMAT = 3, } ToastCompressionId; ``` For an extended format we add a varint (utf8-like) bitmask right after varatt_external that marks the features supported in this particular instance of the pointer. The rest of the data is interpreted depending on the bits set. This will allow us to extend the pointers indefinitely. Note that the proposed approach doesn't require running any migrations. Note also that I described only the on-disk representation. We can tweak the in-memory representation as we want without affecting the end user. Thoughts? [1]: https://commitfest.postgresql.org/43/3626/ [2]: https://git.postgresql.org/gitweb/?p=postgresql.git;a=blob;f=src/include/postgres.h;h=0446daa0e61722067bb75aa693a92b38736e12df;hb=164d174bbf9a3aba719c845497863cd3c49a3ad0#l178 -- Best regards, Aleksander Alekseev