And I am certainly fine with allowing this to be a setting between the 3 approaches: 1) Current approach using multiple loaders 2) Single loader approach using nulls to "fill out" slots 3) Single loader approach re-using keys to "fill out" slots
On 05/17/2012 10:42 AM, Steve Ebersole wrote: > Besides, how is the plan any different for: > > ((id = null) OR (id = null) OR (id = null) OR (id = 4) OR (id = 5)) > > > On Thu 17 May 2012 10:40:57 AM CDT, Steve Ebersole wrote: >> Its an index scan, totally trivial (unless their index hashing algos >> are awful as well). >> >> >> On Thu 17 May 2012 08:49:06 AM CDT, Guillaume Smet wrote: >>> On Thu, May 17, 2012 at 3:02 PM, Steve Ebersole<st...@hibernate.org> >>> wrote: >>>> But just because you have 100 values in no way indicates how many >>>> rows will >>>> be returned. And I personally know of no optimizers that make such an >>>> assumption; its a totally worthless assumption. >>> >>> That's why I put "simplified" in front of it. >>> >>> The number of clauses is taken into account to calculate the >>> estimation of the number of rows returned and depending on the plan >>> chosen to get the results, this might lead to results you don't expect >>> and don't want. >>> >>> See the below example on PostgreSQL (which is far from having the >>> worst optimizer/planner of the market): >>> sitra=# explain select id from objettouristique where id=4 or id=4 or >>> id=4 or id=4 or id=5; >>> QUERY PLAN >>> ------------------------------------------------------------------------------------------ >>> >>> >>> >>> Bitmap Heap Scan on objettouristique (cost=1.80..2.41 rows=5 width=8) >>> Recheck Cond: ((id = 4) OR (id = 4) OR (id = 4) OR (id = 4) OR (id = >>> 5)) >>> -> BitmapOr (cost=1.80..1.80 rows=5 width=0) >>> -> Bitmap Index Scan on objettouristique_pkey >>> (cost=0.00..0.36 rows=1 width=0) >>> Index Cond: (id = 4) >>> -> Bitmap Index Scan on objettouristique_pkey >>> (cost=0.00..0.36 rows=1 width=0) >>> Index Cond: (id = 4) >>> -> Bitmap Index Scan on objettouristique_pkey >>> (cost=0.00..0.36 rows=1 width=0) >>> Index Cond: (id = 4) >>> -> Bitmap Index Scan on objettouristique_pkey >>> (cost=0.00..0.36 rows=1 width=0) >>> Index Cond: (id = 4) >>> -> Bitmap Index Scan on objettouristique_pkey >>> (cost=0.00..0.36 rows=1 width=0) >>> Index Cond: (id = 5) >>> >>> It sure looks stupid but the opinion of the PostgreSQL hackers is that >>> it's stupid to add several times the same clause. The cost of checking >>> all the conditions can be high and is wasted most of the time. >>> >> >> -- >> st...@hibernate.org >> http://hibernate.org > > -- > st...@hibernate.org > http://hibernate.org _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
