[postgis-devel] Validity flag

[Hugo Mercier]

Hi,

I am trying to resurrect our work on validity flag(s).

Does something change with PostGIS 3 ?
In particular, if we are ok to introduce a breaking change, how about
changing the internal binary representation to insert some more bytes of
flags in front of the geometry data rather than at the end ?

On 07/03/2016 18:06, Paul Ramsey wrote:
> 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
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/postgis-devel
>