[postgis-devel] Validity flag

[Paul Ramsey]

On Mon, Mar 7, 2016 at 8:20 AM, Sandro Santilli <strk at keybit.net> wrote:
> On Mon, Mar 07, 2016 at 03:00:48PM +0100, Hugo Mercier wrote:
>> On 06/03/2016 18:15, Paul Ramsey wrote:
>> > It's a quick read at the front, rather than a full traversal to the end.
>> > You can't know where the end is without parsing the stuff in the middle.
>>
>> Can't we ?
>> Since it's a varlena, we have access to the total size of the
>> GSERIALIZED right ? So it seems to be a simple pointer arithmetic. Or am
>> I missing something ?
>
> I was thinking the same. We can just jump to the end (and proceed
> backward, if another "extend" flag is found).
>
> What I'm not sure about is the implication of the double slice
> in terms of performance. At the bare minimum for a big geometry
> you'd be reading two blocks rather than one (the header
> and the footer, if available), in the worst scenario PostgreSQL
> would need to decompress the whole data in order to get the
> final slice (but the same could be true for the initial slice).
>
> But all of this really only matters for the cases in which you
> have a function that does _not_ need to deserialize the geometry,
> and those kind of functions are not very frequently used.

It's counter to my sense of aesthetics, but as long as it's paired
with a "has caboose" flag at the front it mostly doesn't cause any
harm. It will have to be quite carefully done, as there will be quite
a fiew places in current code where size of payload = varhdrsz -
something, and that will need to be altered, but that was true
anyways.

P