| 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
| 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 |