On 06/19/2017 05:19 PM, David G. Johnston wrote:
> At first glance I think I'd rather have it do the correct thing all of
> the time, even if it takes longer, so that my only trade-off decision
> is whether to improve performance by fixing the application.
>
> Ideally if the input tuple wouldn't require compression we wouldn't
> bother to decompress the stored tuple.
That looks like one reasonable elimination check.
I wonder how much closer it could get with some changes that wouldn't
necessarily use many more cycles.
One might be a less_easy queue; marching through the tuple
comparing fields, if one is found to be TOASTed, throw it
on the queue and march on. Only if all the easy ones matched
is there any point in looking at the queue.
At that point, there could be a tunable for how much effort
to expend. Perhaps I'm willing to decompress an inline value,
but not retrieve an out-of-line one? For the TOAST compression
algorithm I'm not sure of the balance between compression
and decompression effort; I know gzip decompression is pretty cheap.
-Chap
