Subject | Re: [IBO] skip metadata to increase remote speed? |
---|---|
Author | Raymond Kennington |
Post date | 2002-11-28T07:13:37Z |
hkuser2001 wrote:
Here's an idea that others will tell you not to do, but has cut the preparation-time of queries significantly for me
with IB 5.
Work out the optimal PLAN for each query and provide it explicitly in the SELECT statement.
To do this, start with the PLAN that is provided by the tool you are using to see what PLAN would currently be used.
Mostly, this is the correct PLAN to use. Try this and if it speeds up the preparation then use it.
For complex queries with JOINs and nested SELECT statements the PLAN provided by the above step was sometimes completely
wrong (with IB5). Then you'll have to work them out by analysis of the JOINs and sub-SELECTs.
Please post your results.
--
Raymond Kennington
Programming Solutions
W2W Team B
>Part of the delay is in determining the PLAN(s).
> Dear all,
>
> I am using IBO4.2Ib on WinXP. The server is Firebird 1.0 stable
> release version (tried both Linux/ WinXP versions).
>
> Connection to server with effective throughput of 512Kbps.
>
> When I initially open a IB_Query which only needs to returns a few
> rows, it takes up to 7 secs. Subsequent open is much faster, within
> 1 to 2 seconds. I used the monitor to find that, in the initial open,
> most time is spent on getting metadata and table structure , like:
> "SELECT S.RDB$FIELD_NAME ..."
>
> Can I make the Query to skip this? Becuase sometimes I only want to
> run a very simple query, I don't need these metadata. I am afraid my
> client will not accept the initial delay.
>
Here's an idea that others will tell you not to do, but has cut the preparation-time of queries significantly for me
with IB 5.
Work out the optimal PLAN for each query and provide it explicitly in the SELECT statement.
To do this, start with the PLAN that is provided by the tool you are using to see what PLAN would currently be used.
Mostly, this is the correct PLAN to use. Try this and if it speeds up the preparation then use it.
For complex queries with JOINs and nested SELECT statements the PLAN provided by the above step was sometimes completely
wrong (with IB5). Then you'll have to work them out by analysis of the JOINs and sub-SELECTs.
Please post your results.
--
Raymond Kennington
Programming Solutions
W2W Team B