[postgis-devel] Validity flag

[Hugo Mercier]

Hi,

We have some days to work on that topic in the two weeks coming.

Reading back this thread, it seems one remaining concern is to decide
how many bits are needed to carry validity information:
- how many states to distinguish: either Valid/Unknown or
Valid/Invalid/Unknown
- what to do with different validity results between geos and sfcgal

On 29/10/2018 17:22, Paul Ramsey wrote:
> 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
> 
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>