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 is that ---
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)
Sort
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
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 standard
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 and
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 it's
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 expression
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 like it's
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 talking about opf
[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 sets
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
inter-relate than just
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 meaning.
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
-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 a bit of
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 like it
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 troop gang
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 ensemble
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.
Done, unless
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 came up with
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 is
Martijn van Oosterhout kleptog@svana.org 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)
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 ?
--
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:
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
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 classes
-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 can
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
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 [, ...])
} [, ... ]
plus a
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? So
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
Martijn van Oosterhout kleptog@svana.org 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
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 opclass for
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. Those
Martijn van Oosterhout kleptog@svana.org 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
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 operator classes. (I'm not wedded to the name class
group; it seems
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
Martijn van Oosterhout kleptog@svana.org 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
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, I
[ 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 of
39 matches
Mail list logo
