Re: lazy detoasting - Mailing list pgsql-hackers

From Tom Lane
Subject Re: lazy detoasting
Date
Msg-id 27405.1526566241@sss.pgh.pa.us
Whole thread Raw
In response to Re: lazy detoasting  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> In reviewing the committed patch, I noticed that in ER_get_flat_size()
> you have removed the PG_DETOAST_DATUM() call and let
> expanded_record_set_field_internal() do the de-toasting work.  I had
> considered that too, but my impression is that the purpose of the
> PG_DETOAST_DATUM() is to de-compress for the purpose of size
> computation, whereas expanded_record_set_field_internal() only does the
> inlining of externally stored values and doesn't do any explicit
> decompression.  Is this correct?

Hmm ... yeah, there is a semantics change there, but I think it's fine.
I don't recall that I'd thought specifically about the behavior for
inline-compressed/short-header Datums when I wrote that code to begin
with.  But for its purpose, which is that we're trying to flatten the
expanded record into a tuple, leaving an inline-compressed field in that
form seems OK, perhaps actually preferable.  And short-header is a no-op:
it'd end up with a short header in the emitted tuple regardless of our
choice here.

            regards, tom lane


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: SCRAM with channel binding downgrade attack
Next
From: Tom Lane
Date:
Subject: Re: Incorrect comment in get_partition_dispatch_recurse