[postgis-devel] Validity flag

[Paul Ramsey]

Ooop, this train is coming down the tracks faster than I thought… yes, more header space is on the agenda… I guess I better get a proposal together… what’s your timeline, Hugo?

P

> On Oct 29, 2018, at 7:13 AM, Hugo Mercier <hugo.mercier at oslandia.com> wrote:
> 
> 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
>> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel