Horton

Re: Compressed TOAST Slicing

Andrey Borodin <x4mmm@yandex-team.ru>

View thread
From: Andrey Borodin <x4mmm@yandex-team.ru>
To: Paul Ramsey <pramsey@cleverelephant.ca>
Cc: Владимир Лесков <vladimirlesk@yandex-team.ru>, Stephen Frost <sfrost@snowman.net>, Daniel Verite <daniel@manitou-mail.org>, Simon Riggs <simon@2ndquadrant.com>, rafia.sabih@enterprisedb.com, Tom Lane <tgl@sss.pgh.pa.us>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>
Date: 2019-04-09T17:17:50Z
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. Add support for partial TOAST decompression

  2. Remove remaining hard-wired OID references in the initial catalog data.

  3. Rephrase references to "time qualification".


> 9 апр. 2019 г., в 22:12, Paul Ramsey <pramsey@cleverelephant.ca> написал(а):
> 
> Wow, well beyond slicing, just being able to decompress 25% faster is a win for pretty much any TOAST use case. I guess the $100 question is: portability? The whole reason for the old-skool code that’s there now was concerns about memcpy’ing overlapping addresses and Bad Things happening.

Yeah, I've observed Bad Things (actually pretty cool and neat things) during memcpy of overlapping regions even on my laptop.
But here we never copy overlapping addresses in one memcpy() call.

Though my tests are very synthetic. Do we have a natural way to demonstrate a performance improvement? Like reference pile of bytes...

Best regards, Andrey Borodin.