Re: Compressed TOAST Slicing

From: Andrey Borodin <x4mmm(at)yandex-team(dot)ru>
To: Paul Ramsey <pramsey(at)cleverelephant(dot)ca>
Cc: 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-03-12 05:22:45
Message-ID: 38DB2538-3D3F-4363-825C-045E68F3D1EA@yandex-team.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi!

> 21 февр. 2019 г., в 23:50, Paul Ramsey <pramsey(at)cleverelephant(dot)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.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Michael Paquier 2019-03-12 05:42:14 Re: Compressed TOAST Slicing
Previous Message Michael Paquier 2019-03-12 05:19:28 Re: Adding a TAP test checking data consistency on standby with minRecoveryPoint