On 05/17/2012 11:53 AM, Andrej Golovnin wrote:
> Hi Steve,
>
>> Deferring initialization of these batch loaders is one option, but that just
>> really delays the memory consumption. Personally, if it were my app I'd
>> rather that sizing be done up front rather than over the course of the next
Sanne, the "problem" discussed here is not the size of the statements
nor the number of rows returned. Its the number of statements
generated and maintained in memory by Hibernate.
Thats being said, I wholeheartedly agree about people trying extremes
as the solution to a problem. An extreme i
On 17 May 2012 17:53, Andrej Golovnin wrote:
> Hi Steve,
>
>> Deferring initialization of these batch loaders is one option, but that just
>> really delays the memory consumption. Personally, if it were my app I'd
>> rather that sizing be done up front rather than over the course of the next
>
On Thu, May 17, 2012 at 6:53 PM, Andrej Golovnin 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 I
Hi Steve,
> And I am certainly fine with allowing this to be a setting between the 3
> approaches:
> 1) Current approach using multiple loaders
-1
> 2) Single loader approach using nulls to "fill out" slots
> 3) Single loader approach re-using keys to "fill out" slots
+1 for any of the above b
Hi Steve,
> Deferring initialization of these batch loaders is one option, but that just
> really delays the memory consumption. Personally, if it were my app I'd
> rather that sizing be done up front rather than over the course of the next
> few hours or weeks as the system continues to run.
On Thu, May 17, 2012 at 5:40 PM, Steve Ebersole 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
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:
> Bes
Besides, how is the plan any different for:
((id = null) OR (id = null) OR (id = null) OR (id = 4) OR (id = 5))
On 05/17/2012 10:40 AM, 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, Gu
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 wrote:
>> But just because you have 100 values in no way indicates how many rows will
>> be return
On Thu, May 17, 2012 at 3:02 PM, Steve Ebersole 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
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.
Nor is this "lack of de-dupping" any real issue that that I can think
of.
On Thu 17 May 2012 07:16:
Hi Steve,
On the list again, my bad...
On Thu, May 17, 2012 at 1:07 PM, Steve Ebersole wrote:
> I am not following what you are saying about "reusing keys" and optimizers.
> Nor how it might lead to bad execution plans. Can you elaborate on your
> thoughts here?
If you have a lot of (OR prima
Hi Eric,
> One option we use on our uPortal installs is to enable
> -XX:+UseCompressedStrings
The support for compressed strings were removed in JDK 7.
Best regards,
Andrej Golovnin
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://
14 matches
Mail list logo
