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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
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[]

Mm.
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
case...

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
psql/general

Regards,
Pierre

In response to

Responses

Browse pgsql-performance by date

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