extended operator classes vs. type interfaces
in [PgSql]
|
Prev: a faster compression algorithm for pg_dump
Next: [HACKERS] How to modify default Type (TSQuery) behaviour?
From: Jeff Davis on 10 Apr 2010 14:30 On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote: > I was thinking of a case for instance for ranges a,b,c in relations > A,B,C respectively, where a && b and b && c, but not a && c. Would the > planner consider a join path of table A and C first, then that result > with B. After looking in doxygen, it looks like having && defined > without MERGES is what prevents this unwanted behaviour, since that > prevents a,b and c to become members of the same equivalence class. Interesting, I would have to make sure that didn't happen. Most likely there would be a new property like "RANGEMERGES", it wouldn't reuse the existing MERGES property. > Sorry for the spam on the list. Not at all, it's an interesting point. Regards, Jeff Davis -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 10 Apr 2010 15:02 On Fri, Apr 9, 2010 at 5:49 PM, Jeff Davis <pgsql(a)j-davis.com> wrote: > On Thu, 2010-04-08 at 22:29 -0400, Robert Haas wrote: >> 1. knngist wants to use index scans to speed up queries of the form >> SELECT ... ORDER BY <column> <op> <constant> (as opposed to the >> existing machinery which only knows how to use an index for SELECT ... >> ORDER BY <column>). >> 2. Window functions want to define windows over a range of values >> defined by the underlying data type. To do this, we need to define >> what addition and subtraction mean for a particular data type. >> 3. Jeff Davis is interested in implementing range types. When the >> underlying base type is discrete, e.g. integers, you can say that >> [1,3] = [1,4), but only if you know that 3 and 4 are consecutive (in >> that order). > > To give some context, I started a thread a while ago: > > http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php > > Tom provided some interesting suggestions in that thread, but I'm not > sure they would work for #1 or #2. <rereads thread> The "map && to <<" case is interesting. It doesn't seem like it's really a good candidate for type interfaces, because you you're not really looking for "the" strictly-left-of operator; you're looking for the strictly-left-of operator associated with the overlaps operator actually specified. And ideally there might be an index strategy number available for <<, too, so that you could consider doing an index scan instead of a sort, but not necessarily. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 10 Apr 2010 15:04 On Sat, Apr 10, 2010 at 2:30 PM, Jeff Davis <pgsql(a)j-davis.com> wrote: > On Sat, 2010-04-10 at 20:25 +0200, Yeb Havinga wrote: >> I was thinking of a case for instance for ranges a,b,c in relations >> A,B,C respectively, where a && b and b && c, but not a && c. Would the >> planner consider a join path of table A and C first, then that result >> with B. After looking in doxygen, it looks like having && defined >> without MERGES is what prevents this unwanted behaviour, since that >> prevents a,b and c to become members of the same equivalence class. > > Interesting, I would have to make sure that didn't happen. Most likely > there would be a new property like "RANGEMERGES", it wouldn't reuse the > existing MERGES property. > >> Sorry for the spam on the list. > > Not at all, it's an interesting point. Yeah... I agree. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Bruce Momjian on 14 Apr 2010 20:48 Robert Haas wrote: > On Fri, Apr 9, 2010 at 11:07 AM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > > > >> From the implementers perspective, IMHO an extra catalog entry in pg_type > >> is not bad on its own, you would have one anyway if the range type was > >> explicitly programmed. About different kinds of range types - I would not > >> know how to 'promote' integer into anything else but just one kind of 'range > >> of integer' type. So the number of extra pg_types would be more like > >> O(number of linear ordered base types). > > > > .. I now see the example of different ranges in your original mail with > > different unit increments. Making that more general so there could be > > continuous and discrete ranges and for the latter, what would the increment > > be.. OTOH is a range of integers with increment x a different type from > > range of integers with increment y, if x<>y? Maybe the increment step and > > continuous/discrete could be typmods. > > Nope, not enough bits available there. This is fundamentally why the > typid/typmod system is so broken - representing a type as a fixed size > object is extremely limiting. A fixed size object that MUST consist > of a 32-bit unsigned OID and a 32-bit signed integer is even more > limiting. You mean the typmod system we developed 13 years ago needs updating? Seems unlikely. ;-) -- Bruce Momjian <bruce(a)momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Scott Bailey on 17 Apr 2010 02:18
Jeff Davis wrote: > On Fri, 2010-04-09 at 12:50 -0500, Kevin Grittner wrote: >> I just thought that if you were adding more type information, >> oriented aournd the types themselves rather than index AMs, some form >> of inheritence might fit in gracefully. > > There are already some specific proposals for inheritance in database > theory literature. For instance: "Databases, Types, and the Relational > Model" by C.J. Date addresses inheritance explicitly (and the appendices > have some interesting discussion). > > I'm not sure how compatible it is with SQL, though; and I am not very > optimistic that we could accomplish such a restructuring of the type > system while maintaining a reasonable level of backwards compatibility. > > Either way, I think it's a separate topic. Two types that are not > related by any subtype/supertype relationship (like strings and ints) > can conform to the same interface (total ordering); while the very same > type can conform to two different interfaces. > > Regards, > Jeff Davis Well I've been doing a lot of work with range abstract data types in Oracle lately. And I've got to say that the OO features in Oracle make it really nice. Of course its Oracle, so its like a half baked OO in cobol syntax, lol. But I for one think it would be great if Postgres had object data types that had methods and could be subclassed. For those not familiar with ADT's in Oracle, here's an example: CREATE TYPE period AS OBJECT ( beginning DATE, ending DATE, CONSTRUCTOR FUNCTION period ( self IN OUT NOCOPY period, beginning DATE, ending DATE ) RETURN SELF AS RESULT, -- config functions MEMBER FUNCTION granule RETURN INTERVAL DAY TO SECOND, MEMBER FUNCTION def_inc RETURN NUMBER, MEMBER FUNCTION range_union(p2 period) RETURN period ... ) NOT FINAL; CREATE TYPE date_range UNDER period ( OVERRIDING MEMBER FUNCTION granule RETURN INTERVAL DAY TO SECOND, OVERRIDING MEMBER FUNCTION def_inc RETURN NUMBER, ... ); Scott Bailey -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |