| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Andres Freund <andres(at)anarazel(dot)de> |
| Cc: | Paul Ramsey <pramsey(at)cleverelephant(dot)ca>, Andrey Borodin <x4mmm(at)yandex-team(dot)ru>, Владимир Лесков <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, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Compressed TOAST Slicing |
| Date: | 2019-04-09 17:30:22 |
| Message-ID: | 22617.1554831022@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2019-04-09 10:12:56 -0700, Paul Ramsey wrote:
>> 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.
> Just use memmove? It's usually as fast these days.
If I recall what this is trying to do, memmove will give the wrong
result. We want the expansion to replicate the same data multiple
times, which in normal use of memcpy/memmove would be thought to be
the Wrong Thing.
The proposal is kind of cute, but I'll bet it's a net loss for
small copy lengths --- likely we'd want some cutoff below which
we do it with the dumb byte-at-a-time loop.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robbie Harwood | 2019-04-09 17:36:26 | Re: [PATCH v20] GSSAPI encryption support |
| Previous Message | Andrey Borodin | 2019-04-09 17:28:14 | Re: Compressed TOAST Slicing |