| From: | Andrey Borodin <x4mmm(at)yandex-team(dot)ru> |
|---|---|
| To: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca> |
| Cc: | Владимир Лесков <vladimirlesk(at)yandex-team(dot)ru>, Stephen Frost <sfrost(at)snowman(dot)net>, Daniel Verite <daniel(at)manitou-mail(dot)org>, Simon Riggs <simon(at)2ndquadrant(dot)com>, rafia(dot)sabih(at)enterprisedb(dot)com, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Compressed TOAST Slicing |
| Date: | 2019-04-09 17:17:50 |
| Message-ID: | 6E49E73C-6B98-4C61-8D91-8A4F5AB0B4CE@yandex-team.ru |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 9 апр. 2019 г., в 22:12, Paul Ramsey <pramsey(at)cleverelephant(dot)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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Andres Freund | 2019-04-09 17:20:49 | Re: Compressed TOAST Slicing |
| Previous Message | Paul Ramsey | 2019-04-09 17:12:56 | Re: Compressed TOAST Slicing |