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

Re: [SQL] OFFSET impact on Performance???

From: PFC <lists(at)boutiquenumerique(dot)com>
To: "Oleg Bartunov" <oleg(at)sai(dot)msu(dot)su>
Cc: alex(at)neteconomist(dot)com, "Greg Stark" <gsstark(at)mit(dot)edu>,"Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com>,"Andrei Bintintan" <klodoma(at)ar-sd(dot)net>,pgsql-performance(at)postgresql(dot)org
Subject: Re: [SQL] OFFSET impact on Performance???
Date: 2005-01-27 16:44:15
Message-ID: opsk9sr1qoth1vuj@musicbox (view raw, whole thread or download thread mbox)
Lists: pgsql-performance
>> 	However, it seems that integer && integer[] does not exist :
> Try intset(id) && int[]. intset is an undocumented function :)
> I'm going to add intset() to README.
>>> SELECT * FROM table WHERE id && int[]

	intset(x) seems to be like array[x] ?
	Actually what I want is the opposite. I have a btree index on an integer  
column ; I wanted to use this index and not create a functional index...  
which is why I wanted to use =ANY(). If I had a gist index on an integer  
array column, I would of course use what you suggest, but this is not the  

	Anyway I think the SRF function solution works well, I like it.

	Note that int_agg_final_array() crashes my postgres, see my message in  


In response to


pgsql-performance by date

Next:From: Josh BerkusDate: 2005-01-27 16:56:03
Subject: Re: Ideal disk setup for Postgresql 7.4?
Previous:From: Christopher Kings-LynneDate: 2005-01-27 16:41:15
Subject: Re: Flattening a kind of 'dynamic' table

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