Horton

Re: Optimize partial TOAST decompression

Rushabh Lathia <rushabh.lathia@gmail.com>

View thread
From: Rushabh Lathia <rushabh.lathia@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>, Tomas Vondra <tomas.vondra@2ndquadrant.com>
Cc: Andrey Borodin <x4mmm@yandex-team.ru>, Alvaro Herrera <alvherre@2ndquadrant.com>, Binguo Bao <djydewang@gmail.com>, Paul Ramsey <pramsey@cleverelephant.ca>, Pgsql Hackers <pgsql-hackers@postgresql.org>
Date: 2019-11-14T09:57:42Z
Lists: pgsql-hackers

Commits

Same data as JSON: GET /api/v1/messages/:b64id/commits the thread's linked commits as JSON, with link sources. API reference →

  1. Properly determine length for on-disk TOAST values

  2. Blind attempt to fix pglz_maximum_compressed_size

  3. Optimize partial TOAST decompression

Today I noticed strange behaviour, consider the following test:

postgres@126111=#create table foo ( a text );
CREATE TABLE
postgres@126111=#insert into foo values ( repeat('PostgreSQL is the
world''s best database and leading by an Open Source Community.', 8000));
INSERT 0 1

postgres@126111=#select substring(a from 639921 for 81) from foo;
 substring
-----------

(1 row)

Before below commit:

commit 540f31680913b4e11f2caa40cafeca269cfcb22f
Author: Tomas Vondra <tomas.vondra@postgresql.org>
Date:   Tue Oct 1 16:53:04 2019 +0200

    Blind attempt to fix pglz_maximum_compressed_size

    Commit 11a078cf87 triggered failures on big-endian machines, and the
    only plausible place for an issue seems to be that TOAST_COMPRESS_SIZE
    calls VARSIZE instead of VARSIZE_ANY. So try fixing that blindly.

    Discussion:
https://www.postgresql.org/message-id/20191001131803.j6uin7nho7t6vxzy%40development

postgres@75761=#select substring(a from 639921 for 81) from foo;

                                    substring

----------------------------------------------------------------------------------
 PostgreSQL is the world's best database and leading by an Open Source
Community.
(1 row)