On Thu, May 17, 2012 at 6:53 PM, Andrej Golovnin <golov...@gmx.net> wrote: > Query: SELECT * FROM test WHERE oid IN (100, 101, 102, 100, 100, 100); > "Index Scan using test_pkey on public.test (cost=0.00..29.72 rows=*6* > width=9) (actual time=0.024..0.034 rows=3 loops=1)" > > Query: SELECT * FROM test WHERE oid IN (100, 101, 102, null, null, null); > "Index Scan using test_pkey on public.test (cost=0.00..29.69 rows=*3* > width=9) (actual time=0.023..0.033 rows=3 loops=1)" > > As you see the difference is only in the calculated costs.
And in the estimation of the number of rows returned. At least on PostgreSQL, the last query is more accurate because the estimated row count is what we want. When you have a lot of joins, even a slight difference in an estimated row count can lead to quite different plans. > If you want, I could show on monday explain output from MySQL 5.5 and Oracle > 11g. Might be interesting. _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
