From: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
---|---|
To: | <pgsql-hackers(at)postgresql(dot)org>, <pgman(at)candle(dot)pha(dot)pa(dot)us> |
Cc: | <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | haskeytype and index_formtuple |
Date: | 2001-05-29 14:12:20 |
Message-ID: | Pine.GSO.4.33.0105291629270.14271-100000@ra.sai.msu.su |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
to continue discussion about pg_index.haskeytype
(see http://fts.postgresql.org/db/mw/msg.html?mid=117845
http://fts.postgresql.org/db/mw/msg.html?mid=119796
)
I'd like to remind that pg_index.haskeytype *was used* up to 7.1
version. It's indicate that type of key is different from that of column !
in 7.0.2 it was possible to use following syntax:
create table TT (i int);
create index TTx on TT using gist (i:intrange gist_intrange_ops);
i:intrange indicates that type of key is intrange while column 'i' has
type int. So, index_formtuple used length of key from intrange.
pg_index.haskeytype was a flag which indicates to index_formtuple to use
information about key from other type. In this example - use intrange
instead of int.
In 7.1 version pg_index.haskeytype is always true, i.e. type of
key is always the same as type of column and syntax 'i:intrange'
became unavailable. Notice, that for fixed length columns it's
necessary that lengths of key and column must be the same.
I don't think we need to restore pg_index.haskeytype and syntax
because:
1. This is not suited for multi-key GiST - we need something like this
for each subkey
2. Syntax is very ugly and useless - all information (type of key, losiness)
should be stored somewhere in system tables.
In such sense,
we vote pg_index.haskeytype could be totally removed from current sources.
Tom, would you like to implement storage for type of key suitable for
multi-key ? It's very important for correct implementation of GiST
we're working on. We have implemented multi-key GiST (posted) and
R-Tree ops for GiST (full implementation, posted with workaround
for poly_ops - key is variable length but length is constant
and equal 36 bytes = sizeof(BOX)+key_length ). Currently we're
implementing B-Tree opses but we have problems because while
types of key and column are fixed but length of key is greater than that
of column type. Again, we need index_formtuple which knows type of key !
Regards,
Oleg
7.0.3 backend/catalog/index.c
indexForm->indhaskeytype = 0;
while (attributeList != NIL)
{
IndexKey = (IndexElem *) lfirst(attributeList);
if (IndexKey->typename != NULL)
{
indexForm->indhaskeytype = 1;
break;
}
attributeList = lnext(attributeList);
}
7.1
indexForm->indhaskeytype = true; /* not actually used anymore */
7.0.3
backend/parser/gram.y
index_elem: attr_name opt_type opt_class
{
$$ = makeNode(IndexElem);
$$->name = $1;
$$->args = NIL;
$$->class = $3;
$$->typename = $2;
}
;
7.1
index_elem: attr_name opt_class
{
$$ = makeNode(IndexElem);
$$->name = $1;
$$->args = NIL;
$$->class = $2;
}
;
_____________________________________________________________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg(at)sai(dot)msu(dot)su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83
From | Date | Subject | |
---|---|---|---|
Next Message | The Hermit Hacker | 2001-05-29 14:13:07 | Re: appendum: Re: *really* simple select doesn't use indices ... |
Previous Message | Tom Lane | 2001-05-29 13:54:47 | Re: appendum: Re: *really* simple select doesn't use indices ... |