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: Robert Haas on 9 Apr 2010 19:55 On Fri, Apr 9, 2010 at 7:53 PM, Robert Haas <robertmhaas(a)gmail.com> wrote: > On Fri, Apr 9, 2010 at 7:18 PM, Nathan Boley <npboley(a)gmail.com> wrote: >>> The advantage of specifying a + and a - in the type interface is that >>> the unit definition can then be specified as part of the type >>> declaration itself. So you can do: >>> >>> CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s'); >>> CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m'); >>> >>> All of the stuff about defining + and - is hidden from the user - it's >>> part of the type interface, which is pre-created. >> >> The disadvantage is that it does not permit irregularly spaced units. > > True. The only types I can think of that have irregularly spaced > units would be things based on floating points, and I was assuming > that people would only want continuous intervals on those. If someone > really wants to be able to deduce that [1.0,3.0) = [1.0,3.0-epsilon), > then we need a different design. But I find it hard to believe that's > very useful. Maybe you feel otherwise? Er, that [1.0,3.0) = [1.0,3.0-epsilon], rather. ....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: Yeb Havinga on 10 Apr 2010 02:26 Robert Haas wrote: > The advantage of specifying a + and a - in the type interface is that > the unit definition can then be specified as part of the type > declaration itself. So you can do: > > CREATE TYPE ts_sec AS RANGE OVER timestamp (UNIT = '1s'); > CREATE TYPE ts_min AS RANGE OVER timestamp (UNIT = '1m'); > The problem with mixing units with ranges is that units are properties of some underlying datatype but not all types on which ranges can be defined. regards, Yeb Havinga -- 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: Yeb Havinga on 10 Apr 2010 12:05 Jeff Davis wrote: > To give some context, I started a thread a while ago: > > http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php > Interesting, a join type for overlaps, which makes me think a bit of the staircase join for pre-post coordinates. However, does a join operator type need certain kinds of properties of the operator involved, e.g. being commutative, transitive etc? Else the join reordering fails. The latter fails for the overlap operator. regards, Yeb Havinga -- 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 12:23 On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > Jeff Davis wrote: >> >> To give some context, I started a thread a while ago: >> >> http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php >> > > Interesting, a join type for overlaps, which makes me think a bit of the > staircase join for pre-post coordinates. However, does a join operator type > need certain kinds of properties of the operator involved, e.g. being > commutative, transitive etc? Else the join reordering fails. The latter > fails for the overlap operator. I don't think I follow this. As far as I know, the join order constraints don't depend on the choice of operator. ....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: Yeb Havinga on 10 Apr 2010 14:25
Robert Haas wrote: > On Sat, Apr 10, 2010 at 12:05 PM, Yeb Havinga <yebhavinga(a)gmail.com> wrote: > >> Jeff Davis wrote: >> >>> To give some context, I started a thread a while ago: >>> >>> http://archives.postgresql.org/pgsql-hackers/2009-10/msg01403.php >>> >>> >> Interesting, a join type for overlaps, which makes me think a bit of the >> staircase join for pre-post coordinates. However, does a join operator type >> need certain kinds of properties of the operator involved, e.g. being >> commutative, transitive etc? Else the join reordering fails. The latter >> fails for the overlap operator. >> > > I don't think I follow this. As far as I know, the join order > constraints don't depend on the choice of operator. > 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. Sorry for the spam on the list. regards, Yeb Havinga -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |