Subject | Re: [firebird-support] Block size exceeds implementation restriction |
---|---|
Author | Helen Borrie |
Post date | 2006-04-24T23:26:03Z |
At 03:34 AM 25/04/2006, you wrote:
Kb or the query plan is larger than 48 Kb.
Some thoughts:
--Don't overlook the size of data in your parameterised expressions
--Consider the proliferation of bytes in the resolved SQL and the
plan from using IN() (which resolves under the hood to a sometimes
huge number of OR clauselets).
--In fact, if you are using IN() at all, you would do well to
rephrase your query to use EXISTS() instead, wherever possible
--If you are joining to views, remember that the plan could be
exceedingly complex
--Consider places where you might be using joins unnecessarily, where
a correlated subquery might do the trick better and distribute the
load into separate plans
--If the query is such that it is jostling at the outer limits, it's
probably a sign that this op needs to be simplified into a selectable
SP. A 64Kb select statement or a 48 Kb plan is not particularly practicable...
./heLen
>Hello,It means (either or both) that your SQL statement is larger than 64
>
>I am using Firebird 1.5.2 for my project and I encountered one
>problem. When executing a (rather complex) query I get the following
>error messages:
>
>Implementation limit exceeded
>Block size exceeds implementation restriction
>
>Besides Firebird I am using Hibernate for the OR mapping. I have
>searched the web for the description and found only the following page
>http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_fb1_faq
>describing the problem (at the bottom of the page). However, I am not
>sure where exactly the problem is and what does "..expressions do not
>exceed the maximum size of a column..." mean.
Kb or the query plan is larger than 48 Kb.
Some thoughts:
--Don't overlook the size of data in your parameterised expressions
--Consider the proliferation of bytes in the resolved SQL and the
plan from using IN() (which resolves under the hood to a sometimes
huge number of OR clauselets).
--In fact, if you are using IN() at all, you would do well to
rephrase your query to use EXISTS() instead, wherever possible
--If you are joining to views, remember that the plan could be
exceedingly complex
--Consider places where you might be using joins unnecessarily, where
a correlated subquery might do the trick better and distribute the
load into separate plans
--If the query is such that it is jostling at the outer limits, it's
probably a sign that this op needs to be simplified into a selectable
SP. A 64Kb select statement or a 48 Kb plan is not particularly practicable...
./heLen