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
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
