Search Postgresql Archives

Re: Coercing compound types to use generic ROW comparison operators

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/12/07, Tom Lane <tgl@xxxxxxxxxxxxx> wrote:
> "Merlin Moncure" <mmoncure@xxxxxxxxx> writes:
> > AIUI, the biggest problem with the current behavior is that there is
> > no way to usefully index composite types, it looks like
>
> > create index bar_idx on bar(f);
> > create index bar_idx on bar((f).*);
> > create index bar_idx on bar((f).a, (f).b);
>
> The last case works, you just don't have enough parentheses.
>
> regression=# create type mytype as (a int, b float);
> CREATE TYPE
> regression=# create table foo(f mytype);
> CREATE TABLE
> regression=# create index fooi on foo(((f).a), ((f).b));
> CREATE INDEX

wow, thats pretty neat! (although:
create index fooi on foo(((f).a));
feels awfully weird).

for the record, creating indexes this way works fully with row
comparison strategies (in 8.2+):
select * from foo where ((f).a, (f).b) > (5, 0.6) order by (f).a, (f).b limit 1;
will use the 'fooi' index above.

merlin

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux