Re: Optimize partial TOAST decompression

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>

To: 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-10-01T14:10:37Z

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 →

Properly determine length for on-disk TOAST values
- 2dc08bd6179d 13.0 landed
Blind attempt to fix pglz_maximum_compressed_size
- 540f31680913 13.0 landed
Optimize partial TOAST decompression
- 11a078cf87ff 13.0 landed

Tomas Vondra <tomas.vondra@2ndquadrant.com> writes:
> Hmmm, this seems to trigger a failure on thorntail, which is a sparc64
> machine (and it seems to pass on all x86 machines, so far).

gharial's not happy either, and I bet if you wait a bit longer you'll
see the same on other big-endian machines.

> I wonder if that's wrong, somehow ... Maybe it should use VARSIZE_ANY,
> but then how would it work on any platform and only fail on sparc64?

Maybe it accidentally seems to work on little-endian, thanks to the
different definitions of varlena headers?

			regards, tom lane