> C'mon. This ain't bad. *g* Ever tried to do the same with the big guns
> Oracle, MSSQL etc.?

big gum? but Firebird is not a nuclear weapon compare to them ? :)

> I'm afraid, this is only possible (if at all), if your middle-tier is
> somehow caching prepared statements/objects available for being re-used
> by different requests, like a connection pool.

that i can do, i already do a pool of transaction (read only transaction), a pool of connection, why not a pool of statement ? i will study it.

> In one of your previous example, you showed us some timings with ~400ms,
> AFAIR. Now we are down to < 50ms. I'm loosing the context now. ;-)

i m sorry, i mix too much ... i mean when no one is on the server, then the select ... from desc_varchar cost 50 ms (and only 2ms for the select desc_empty) and when their is around 50 user (to simulate our server activities) then the select cost around 400 - 500 ms that is really too much. in fact on our server, when a user that want to retrieve an obj do normally around 20 select on different table (even big) it's cost all around 10 ms + this select that cost 400-500 ms ! so the prepare of this simple select cost 40 times more than all the other select, retrieve, etc...

> I'm afraid, we all are a bit lost on what your problem *really* is.
>
> * What is your system actually doing?

a web server that when user come and want the details of the obj xxx gave to the user all the data associated to the obj xxx (including the description(s))

> * What is your load?

around 50 simultaneouse user... 300 in high load

> * What Firebird version and architecture do you use?

the last (fb 2.5.1), super classic, windows