I bet there is no 'critical' length - this is just another case of index
scan vs. seqscan. The efficiency depends on the size of the table / row,
amount of data in the table, variability of the column used in the IN
clause, etc.
Splitting the query with 1000 items into 10 separate queries, the smaller
queries may be faster but the total time consumed may be actually higher.
Something like
10 * (time of small query) + (time to combine them) > (time of large query)
If the performance of the 'split' solution is actually better than the
original query, it just means that the planner does not use index scan
when it actually should. That means that either
(a) the planner is not smart enough
(b) it has not current statistics of the table (run ANALYZE on the table)
(c) the statistics are not detailed enough (ALTER TABLE ... SET STATICTICS)
(d) the cost variables are not set properly (do not match the hardware -
decreate index scan cost / increase seq scan cost)
regards
Tomas
> On Tue, 18 Nov 2008, Kynn Jones wrote:
>> Also, assuming that the optimal way to write the query depends on the
>> length of $node_list, how can I estimate the
>> "critical length" at which I should switch from one form of the query to
>> the other?
>
> In the past, I have found the fastest way to do this was to operate on
> groups of a bit less than a thousand values, and issue one query per
> group. Of course, Postgres may have improved since then, so I'll let more
> knowledgable people cover that for me.
>
> Matthew
>
> --
> Heat is work, and work's a curse. All the heat in the universe, it's
> going to cool down, because it can't increase, then there'll be no
> more work, and there'll be perfect peace. -- Michael Flanders
>
> --
> Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>
