Re: Compressed TOAST Slicing - Mailing list pgsql-hackers

From Andrey Borodin
Subject Re: Compressed TOAST Slicing
Date
Msg-id 38DB2538-3D3F-4363-825C-045E68F3D1EA@yandex-team.ru
Whole thread Raw
In response to Re: Compressed TOAST Slicing  (Paul Ramsey <pramsey@cleverelephant.ca>)
Responses Re: Compressed TOAST Slicing
Re: Compressed TOAST Slicing
List pgsql-hackers
Hi!

> 21 февр. 2019 г., в 23:50, Paul Ramsey <pramsey@cleverelephant.ca> написал(а):
>
> Merci! Attached are updated patches.
> <compressed-datum-slicing-20190221a.patch><compressed-datum-slicing-left-20190221a.patch>

As noted before, patches are extremely useful.
So, I've looked into the code too.

I've got some questions about pglz_decompress() changes:

1.
+                    if (dp >= destend)    /* check for buffer overrun */
+                        break;        /* do not clobber memory */
This is done inside byte-loop. But can we just calculate len = min(len, destend - dp) beforehand?

2. Function argument is_slice is only preventing error.

+     * If we are slicing, then we won't necessarily
+     * be at the end of the source or dest buffers
+     * when we hit a stop, so we don't test then.

But I do not get why we should get that error. If we have limited dest, why we should not fill it entirely?

3. And I'd use memmove despite the comment why we do not do that. It is SSE-optimized and cache-optimized nowadays.
But this in not point of this patch, so let's discard this point.

Best regards, Andrey Borodin.

pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Adding a TAP test checking data consistency on standby withminRecoveryPoint
Next
From: Michael Paquier
Date:
Subject: Re: Compressed TOAST Slicing