Re: [SQL] OFFSET impact on Performance???
| От | PFC |
|---|---|
| Тема | Re: [SQL] OFFSET impact on Performance??? |
| Дата | |
| Msg-id | opsk9sr1qoth1vuj@musicbox обсуждение исходный текст |
| Ответ на | Re: [SQL] OFFSET impact on Performance??? (Oleg Bartunov <oleg@sai.msu.su>) |
| Ответы |
Re: [SQL] OFFSET impact on Performance???
|
| Список | 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
В списке pgsql-performance по дате отправления: