On Thu, May 17, 2012 at 5:40 PM, Steve Ebersole <st...@hibernate.org> wrote: > Its an index scan, totally trivial (unless their index hashing algos are > awful as well).
It is. Unless you have a lot of LEFT JOINs in the query due to your class hierarchy (that's our case and the resulting queries aren't trivial at all), as I mentioned it in my previous post. On Thu, May 17, 2012 at 5:42 PM, Steve Ebersole <steven.ebers...@gmail.com> wrote: > Besides, how is the plan any different for: > > ((id = null) OR (id = null) OR (id = null) OR (id = 4) OR (id = 5)) It becomes ugly: sitra=# explain select id from objettouristique where id=null or id=null or id=null or id=null or id=5; QUERY PLAN ------------------------------------------------------------------- *Seq* *Scan* on objettouristique (cost=0.00..3220.39 rows=1 width=8) Filter: ((id = 5) OR NULL::boolean) (2 rows) My point isn't that one method is better than the other (well, the = null method is definitely worse...). It is that this matter should be considered carefully as it's not that trivial. Can't we use a dynamic IN()? Or at least, can't it be an option? I don't know this area of the code and it looks like a too simple answer so the question might be stupid... The only problem I see is if it's using prepared statements. FWIW, I also have the same problem the OP has. I was thinking that it was due to our model being bigger than usual but as we use a batch size of 10, I'm pretty sure we are in the same situation. -- Guillaume _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev