From: | strk <strk(at)keybit(dot)net> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | postgis-devel(at)postgis(dot)refractions(dot)net, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: PG7.4 ordering operator |
Date: | 2003-11-20 10:23:09 |
Message-ID: | 20031120112309.A78019@freek.keybit.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
tgl wrote:
> strk <strk(at)keybit(dot)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;
From | Date | Subject | |
---|---|---|---|
Next Message | Ollie Clark | 2003-11-20 11:43:53 | Change in behaviour of ORDER BY clause in PG7.3 |
Previous Message | Andreas Pflug | 2003-11-20 09:40:21 | Re: ALTER COLUMN/logical column position |