Skip site navigation (1) Skip section navigation (2)

Re: [PERFORM] GIST versus GIN indexes for intarrays

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Teodor Sigaev <teodor(at)sigaev(dot)ru>
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 17:20:58
Message-ID: 4854.1234545658@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-performance
Teodor Sigaev <teodor(at)sigaev(dot)ru> writes:
>> 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)

Really?  isort() looks like a bubble sort to me.

But in any case, a pre-sort is probably actually *slower* for small
numbers of array elements.  I wonder where the crossover is.  In
principle we could make the core implementation do a sort when working
with a sortable datatype, but I'm unsure it's worth the trouble.

			regards, tom lane

In response to

pgsql-performance by date

Next:From: Kevin GrittnerDate: 2009-02-13 17:35:29
Subject: Re: I/O increase after upgrading to 8.3.5
Previous:From: Alexander StauboDate: 2009-02-13 16:31:25
Subject: Re: I/O increase after upgrading to 8.3.5

pgsql-hackers by date

Next:From: John ListerDate: 2009-02-13 17:57:11
Subject: Re: Database corruption help
Previous:From: Andrew ChernowDate: 2009-02-13 17:06:09
Subject: Re: PQinitSSL broken in some use casesf

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group