Re: [PERFORM] GIST versus GIN indexes for intarrays

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Rusty Conover <rconover(at)infogears(dot)com>, psql performance <pgsql-performance(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org, Oleg Bartunov <oleg(at)sai(dot)msu(dot)su>
Subject: Re: [PERFORM] GIST versus GIN indexes for intarrays
Date: 2009-02-13 13:12:53
Message-ID: 499571D5.6000906@sigaev.ru
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-performance

> The short-term workaround for Rusty is probably to create his GIN
> index using the intarray-provided gin__int_ops opclass. But it
Right
> seems to me that we ought to get rid of intarray's @> and <@ operators
> and have the module depend on the core anyarray operators, just as we
> have already done for = and <>. Comments?
Agree, will do. Although built-in anyarray operators have ~N^2 behaviour while
intarray's version - only N*log(N)
--
Teodor Sigaev E-mail: teodor(at)sigaev(dot)ru
WWW: http://www.sigaev.ru/

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2009-02-13 14:02:54 Re: GIN fast insert
Previous Message Zdenek Kotala 2009-02-13 13:11:16 Re: pg_upgrade project status

Browse pgsql-performance by date

  From Date Subject
Next Message Rajesh Kumar Mallah 2009-02-13 13:30:50 dissimilar drives in Raid10 , does it make difference ?
Previous Message Alexander Staubo 2009-02-13 11:53:12 I/O increase after upgrading to 8.3.5