Re: PG7.4 ordering operator - Mailing list pgsql-hackers

From strk
Subject Re: PG7.4 ordering operator
Date
Msg-id 20031120112309.A78019@freek.keybit.net
Whole thread Raw
In response to Re: PG7.4 ordering operator  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PG7.4 ordering operator
List 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 by date:

Previous
From: Andreas Pflug
Date:
Subject: Re: ALTER COLUMN/logical column position
Next
From: Oleg Bartunov
Date:
Subject: tsearch2 patch for 7.4.1