datum slicing for bounding box retrieval is busted

[pramsey]

I found that for points/short lines, the box retrieval functions were double-detoasting every time:

• first a slice to pull a box off the slice
• the points have no box so second we detoast the whole thing

The idea of slicing is for large objects to avoid an expensive detoast just to get the box, but…

• postgis uses "storage = main"
• and main storage has a policy to first compress, then use external toast tables

so we are usually going to end up with compressed values in main tables.

But… that means that slicing never works, since the first step in slicing is "decompress the whole thing". At that point we might as well just have the thing back and get to work, the slice gains us nothing.

[pramsey]

In 15778:

Remove slicing logic from bounding box reader and
note why inline with the code so it can be done "right"
in a larger re-work of serialization (postgis 3) that
supports postgis-side compression. (Closes #3853)

[dbaston]

Sounds like this should be a nice boost for point-in-polygon joins. Were you able to benchmark anything before/after?

[strk]

I was under the impression that you didn't get a double detoasting even before, as the Datum pointer would always be the same so second DETOAST attempt would be a no-op.

Just a cheap useless check (always false) in the worst case and an opportunity for users to change storage type (can be done on a table-by-table basis IIRC?) and then benefit from the (now removed) code.

[pramsey]

There was definitely double de-toasting, it showed up in the profile, and things were noticeably faster without it. I'd still like to have a format with our own internal compression so we could have cake and eat it too.