On 06/18/2014 01:46 PM, Andres Freund wrote:
> On 2014-06-18 12:18:26 +0300, Heikki Linnakangas wrote:
>> The main problem with using it for geometric types is that you can't easily
>> CLUSTER the table to make the minmax index effective again. But there are
>> ways around that.
>
> Which are? Sure you can try stuff like recreating the table, sorting
> rows with boundary boxes area above threshold first, and then go on to
> sort by the lop left corner of the bounding box.
Right, something like that. Or cluster using some other column that
correlates with the geometry, like a zip code.
> But that'll be neither
> builtin, nor convenient, nor perfect. In contrast to a normal CLUSTER
> for types with a btree opclass which will yield the perfect order.
Sure.
BTW, CLUSTERing by a geometric type would be useful anyway, even without
minmax indexes.
>>> Isn't 'simpler implementation' a valid reason that's already been
>>> discussed onlist? Obviously simpler implementation doesn't trump
>>> everything, but it's one valid reason...
>>> Note that I have zap to do with the design of this feature. I work for
>>> the same company as Alvaro, but that's pretty much it...
>>
>> Without some analysis (e.g implementing it and comparing), I don't buy that
>> it makes the implementation simpler to restrict it in this way. Maybe it
>> does, but often it's actually simpler to solve the general case.
>
> So to implement a feature one now has to implement the most generic
> variant as a prototype first? Really?
Implementing something is a good way to demonstrate how it would look
like. But no, I don't insist on implementing every possible design
whenever a new feature is proposed.
I liked Greg's sketch of what the opclass support functions would be. It
doesn't seem significantly more complicated than what's in the patch now.
- Heikki
