Dawid Kuroczko <[EMAIL PROTECTED]> writes:
> But when I phrase the query:
> SELECT * FROM table WHERE (icount(ids) <= 1 AND ids[1] = 33) OR
> (icount(ids) > 1 AND ids && '{33}');
> Planner insists on using seqscan. Even with enable_seqscan = off;
The OR-index-scan mechanism isn't currently smar
In article <[EMAIL PROTECTED]>,
=?iso-8859-15?Q?Pierre-Fr=E9d=E9ric_Caillaud?= <[EMAIL PROTECTED]> writes:
> disclaimer : brainless proposition
> (SELECT * FROM table WHERE (icount(ids) <= 1 AND ids[1] = 33)
> UNION ALL
> (SELECT * FROM table WHERE (icount(ids) > 1 AND ids && '{33}'));
I g
disclaimer : brainless proposition
(SELECT * FROM table WHERE (icount(ids) <= 1 AND ids[1] = 33)
UNION ALL
(SELECT * FROM table WHERE (icount(ids) > 1 AND ids && '{33}'));
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
I have a large table with a column:
ids integer[] not null
most of these entries (over 95%) contain only one array element, some
can contain up to 10 array elements. seqscan is naturally slow. GIST
on int_array works nice, but GIST isn't exactly a speed daemon when it
comes to updating.
So I th
