On Tue, Jun 17, 2014 at 10:31 AM, Andres Freund <and...@2ndquadrant.com> wrote: > On 2014-06-17 10:26:11 -0400, Robert Haas wrote: >> On Sat, Jun 14, 2014 at 10:34 PM, Alvaro Herrera >> <alvhe...@2ndquadrant.com> wrote: >> > Robert Haas wrote: >> >> On Wed, Sep 25, 2013 at 4:34 PM, Alvaro Herrera >> >> <alvhe...@2ndquadrant.com> wrote: >> >> > Here's an updated version of this patch, with fixes to all the bugs >> >> > reported so far. Thanks to Thom Brown, Jaime Casanova, Erik Rijkers and >> >> > Amit Kapila for the reports. >> >> >> >> I'm not very happy with the use of a separate relation fork for >> >> storing this data. >> > >> > Here's a new version of this patch. Now the revmap is not stored in a >> > separate fork, but together with all the regular data, as explained >> > elsewhere in the thread. >> >> Cool. >> >> Have you thought more about this comment from Heikki? >> >> http://www.postgresql.org/message-id/52495dd3.9010...@vmware.com > > Is there actually a significant usecase behind that wish or just a > general demand for being generic? To me it seems fairly unlikely you'd > end up with something useful by doing a minmax index over bounding > boxes.
Well, I'm not the guy who does things with geometric data, but I don't want to ignore the significant percentage of our users who are. As you must surely know, the GIST implementations for geometric data types store bounding boxes on internal pages, and that seems to be useful to people. What is your reason for thinking that it would be any less useful in this context? I do also think that a general demand for being generic ought to carry some weight. We have gone to great lengths to make sure that our indexing can handle more than just < and >, where a lot of other products have not bothered. I think we have gotten a lot of mileage out of that decision and feel that we shouldn't casually back away from it. Obviously, we do already have some special-case optimizations and will likely have more in the future, and there are can certainly be valid reasons for taking that approach. But it needs to be justified in some way; we shouldn't accept a less-generic approach blindly, without questioning whether it's possible to do better. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers