"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Merge Join (cost=10149.78..10448.70 rows=13161 width=36)
>>Merge Cond: (a.a = "inner"."?column2?")
>>-> Index Scan using aa on a (cost=0.00..62.45 rows=1230 width=32)
>>-> Sort (cost=100
Gregory Stark <[EMAIL PROTECTED]> writes:
> Merge Join (cost=10149.78..10448.70 rows=13161 width=36)
>Merge Cond: (a.a = "inner"."?column2?")
>-> Index Scan using aa on a (cost=0.00..62.45 rows=1230 width=32)
>-> Sort (cost=10149.78..10155.13 rows=2140 width=4)
>
Hope you had a nice holiday.
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> So the only reason we needed the cross-data-type operators was to get better
>> estimates? I thought without them you couldn't get an index-based plan at
>> all.
>
> Oh, hm, there
Gregory Stark <[EMAIL PROTECTED]> writes:
> So the only reason we needed the cross-data-type operators was to get better
> estimates? I thought without them you couldn't get an index-based plan at all.
Oh, hm, there is that --- you won't get a nestloop with inner indexscan
unless the join expressi
Tom Lane <[EMAIL PROTECTED]> writes:
> No, what you'll get is something like
>
> int4var::float8 float8eq float8var
>
> which is perfectly mergejoinable ... however, it's not clear that the
> planner will make very good estimates about the value of the cast
> expression. I'm not sure if
Gregory Stark <[EMAIL PROTECTED]> writes:
> I thought that would just be formalizing what we currently have. But I just
> discovered to my surprise tat it's not. I don't see any cross-data-type
> operators between any of the integer types and numeric, or between any of the
> floating point types an
"Tom Lane" <[EMAIL PROTECTED]> writes:
> A class group is associated with a specific index AM and can contain only
> opclasses for that AM. We might for instance invent "numeric" and
> "numeric_reverse" groups for btree, to contain the default opclasses and
> reverse-sort opclasses for the stand
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
>> But "opfamid" is a really unfortunate name, because it looks way too
>> much like it's supposed to be the ID of the family itself, rather than
>> of the index AM it's associated with.
> I think by convention it is clear that we are talkin
> pg_opfamily
>
> OID
> opfamid access method OID
> opfname family name
> opfnamespacefamily namespace
> opfownerowner's OID
>
> But "opfamid" is a really unfortunate name, because it looks way too
> much l
"Operator family" seems like it might be a good choice.
>>> I like this one more than opcluster. opfamily has a good ring to it also.
>> +1 on opfamily.
> Done, unless anyone really doesn't like it.
So I started revising my notes on what to change the catalog structure
to, and immediately cam
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> Martijn van Oosterhout wrote:
>> On Sat, Dec 16, 2006 at 11:48:48AM -0500, Tom Lane wrote:
>>> "Operator family" seems like it might be a good choice.
>>
>> I like this one more than opcluster. opfamily has a good ring to it also.
> +1 on opfamily.
Do
Martijn van Oosterhout wrote:
> On Sat, Dec 16, 2006 at 11:48:48AM -0500, Tom Lane wrote:
> > So I finally went and looked at a thesaurus, and came up with some
> > possibilities:
> >
> > category variety family crowd cluster flock pack troop gang clique
> > circle cabal association society union
On Sat, 2006-12-16 at 11:48 -0500, Tom Lane wrote:
> Alvaro Herrera <[EMAIL PROTECTED]> writes:
> > How about "hyperclass" then? :-) Maybe "school" :-D
>
> So I finally went and looked at a thesaurus, and came up with some
> possibilities:
>
> category variety family crowd cluster flock pack tro
On Sat, Dec 16, 2006 at 11:48:48AM -0500, Tom Lane wrote:
> So I finally went and looked at a thesaurus, and came up with some
> possibilities:
>
> category variety family crowd cluster flock pack troop gang clique
> circle cabal association society union ensemble
>
> "Operator family" seems lik
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Dec 16, 2006 at 11:14:02AM -0500, Tom Lane wrote:
> [EMAIL PROTECTED] writes:
> > "Operator class group", unwieldy as it is, conveys the meaning that we
> > are talking about _sets of operator classes_. The nicer terms I have
> > seen all lose
Alvaro Herrera <[EMAIL PROTECTED]> writes:
> How about "hyperclass" then? :-) Maybe "school" :-D
So I finally went and looked at a thesaurus, and came up with some
possibilities:
category variety family crowd cluster flock pack troop gang clique
circle cabal association society union ensemble
Alvaro Herrera wrote:
> The "superclass" term passes that test, but fails because it is somehow
> expected that you can't put a class inside a superclass.
>
> How about "hyperclass" then? :-) Maybe "school" :-D
>
> Maybe somebody should ask a philologist about a greek or latin prefix
> with that
Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Perhaps something like
>
> > Operator Class
> > and
> > Data Type Class
>
> > Data type classes happens to involve operator classes but it sounds like
> > you're looking for them to specify other behaviours of how data types
> > inte
[EMAIL PROTECTED] writes:
> "Operator class group", unwieldy as it is, conveys the meaning that we
> are talking about _sets of operator classes_. The nicer terms I have
> seen all lose a bit of that ring to me.
The thing is that in the proposal as it currently stands, we're *not*
talking about se
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Fri, Dec 15, 2006 at 06:44:10PM -0500, Tom Lane wrote:
> Gregory Stark <[EMAIL PROTECTED]> writes:
> > Operator Superclass ?
>
> Yeah, I thought about that too, but I don't like it much ... can't
> entirely put my finger on why not [...]
I think I
Gregory Stark <[EMAIL PROTECTED]> writes:
> Perhaps something like
> Operator Class
> and
> Data Type Class
> Data type classes happens to involve operator classes but it sounds like
> you're looking for them to specify other behaviours of how data types
> inter-relate than just their operator cl
"Tom Lane" <[EMAIL PROTECTED]> writes:
> Gregory Stark <[EMAIL PROTECTED]> writes:
>> Operator Superclass ?
>
> Yeah, I thought about that too, but I don't like it much ... can't
> entirely put my finger on why not, except that class/superclass usually
> implies that the objects you're talking ab
Gregory Stark <[EMAIL PROTECTED]> writes:
> Operator Superclass ?
Yeah, I thought about that too, but I don't like it much ... can't
entirely put my finger on why not, except that class/superclass usually
implies that the objects you're talking about are all the same kind of
thing, whereas what we
"Tom Lane" <[EMAIL PROTECTED]> writes:
> The main objection I can think of is that a novice seeing the terms
> "operator class" and "operator group" isn't going to have any context
> to know which is which, but I'm not sure that we can devise any terms
> that would help much.
Operator Superclass
Martijn van Oosterhout writes:
> I think we're on the same page. I thought of another motivation also:
> protections/permissions. We don't currently allow people to mess with
> definitions needed by system catalogs, so you don't want to allow users
> to mess with the btree(int4) class, but you wan
On Thu, Dec 14, 2006 at 08:31:59PM -0500, Tom Lane wrote:
> > How the backend implements it may be easier as one single large
> > opclass. Essentially the operater class table becomes merely a
> > placeholder for the name (maybe also aliases?), which can still be used
> > in index declarations, but
Martijn van Oosterhout writes:
> I think it may be useful to maintain the distinction between groups and
> classes for users, because at that level the whole concept is easier to
> understand. Dropping and recreating operator classes is easier to
> handle than playing strange tricks with ALTER OPE
Gregory Stark <[EMAIL PROTECTED]> writes:
> Hm, would we still need all the cross-data-type btree operators?
Yes, I think so; remember all the pain we had when we didn't have
indexable cross-type operators and spent years looking for a non-broken
way of introducing casts to solve the problem. Tho
"Tom Lane" <[EMAIL PROTECTED]> writes:
> I'm not sure. The problem that I'm seeing is that currently, cross-type
> comparisons go into the opclass associated with their left-hand argument
> type. Therefore, if say you want to add "tinyint" to an opclass group,
> you not only need to add an opcla
Martijn van Oosterhout writes:
> I think it may be useful to maintain the distinction between groups and
> classes for users, because at that level the whole concept is easier to
> understand. Dropping and recreating operator classes is easier to
> handle than playing strange tricks with ALTER OPE
"Zeugswetter Andreas ADI SD" <[EMAIL PROTECTED]> writes:
> I think it would be easier to understand if we do not merge the
> opclasses for different types into one statement.
Agreed, huge CREATE OPERATOR CLASS commands would be no fun, which
is one reason for my recommendation to improve ALTER OP
On Wed, Dec 13, 2006 at 07:28:20PM -0500, Tom Lane wrote:
> Some more thought about that yielded what might or might not be a good
> idea: why not just collapse all the members of a "class group" into one
> opclass? In other words, not make a distinction between groups and
> individual opclasses?
> CREATE OPERATOR CLASS name USING index_method AS
> { [ DEFAULT ] FOR TYPE data_type [ STORAGE storage_type ] [
> ALIAS name ]
>| OPERATOR strategy_number operator_name [ (op_type,
> op_type) ] [ RECHECK ]
>| FUNCTION support_number funcname (argument_type [, ...])
> } [, ... ]
>
>
Some more thought about that yielded what might or might not be a good
idea: why not just collapse all the members of a "class group" into one
opclass? In other words, not make a distinction between groups and
individual opclasses? So for example, int2_ops int4_ops and int8_ops
would all collap
[ replying to myself again, how tacky :-( ]
I wrote:
> BTW, I forgot to mention one of the motivations for that last
> restriction: I'm thinking it would be convenient to allow index
> declarations to accept either an opclass name or a class group name.
> Thus you could say "pattern_ops" instead o
I wrote:
> We further require that any given opclass be a member of at most one class
> group (this simplifies matters, and there isn't any application I can see
> for one opclass being in more than one group), and that a class group
> contain at most one opclass for a given datatype (ditto).
BTW,
Martijn van Oosterhout writes:
> On Wed, Dec 13, 2006 at 04:27:09PM -0500, Tom Lane wrote:
>> we should invent the notion of "operator class groups", which identify
>> sets of compatible operator classes.
> I think it's a good idea, though I would point out that in the examples
> given it's the u
On Wed, Dec 13, 2006 at 04:27:09PM -0500, Tom Lane wrote:
> After further thought about the mergejoinable-operators issue and some
> other longstanding planner problems, I have a modest proposal to make:
> we should invent the notion of "operator class groups", which identify
> sets of compatible o
38 matches
Mail list logo
