Re: PG7.4 ordering operator
От | strk |
---|---|
Тема | Re: PG7.4 ordering operator |
Дата | |
Msg-id | 20031120112309.A78019@freek.keybit.net обсуждение исходный текст |
Ответ на | Re: PG7.4 ordering operator (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: PG7.4 ordering operator
|
Список | pgsql-hackers |
tgl wrote: > strk <strk@keybit.net> writes: > > Testing postgis support in PG7.4 (2003-11-11) > > I've encountered to this problem: > > ERROR: could not identify an ordering operator for type geometry > > Previous PG versions does not show this problem. > > Any hint on what might be missing ? > > A default btree operator class for type geometry. PG 7.4 no longer > uses assumptions about operator names to determine sorting/grouping > behavior. If you have some operators that provide a scalar sort > ordering on your datatype, then make a btree opclass to show that. > See > http://www.postgresql.org/docs/7.4/static/xindex.html#XINDEX-OPCLASS-DEPENDENCIES > > regards, tom lane Thanks for the answer, I've one more question: I've provided a default btree operator class but I'm often going out of memory when using DISTINCT or UNION clauses. How can I reduce memory usage in these cases ? Since passed argument are TOASTED, but I use only a small initial portion if them to make the computation, can I avoid DETOASTING them and still reach that initial part ? The information I need is stored at offset 40 from detoasted data and is 6doubles long. I cannot find TOAST documentation. thanks. --strk;
В списке pgsql-hackers по дате отправления: