Hi,

> >(B) will be much faster. Prepared statement aren't re-evaluated,
> >but are "buffered". But only on the connection level, not across
> >different connections.
>
> Is it possible to:
>
> - specify how large the "buffer" can be?

No. Please read again: there's no buffer on the server side. Statements
can be prepared, on a per-connection level. If you keep the statement
handle (in Delphi/Java terms: keep the statement prepared), you can
reuse the statement handle, bind the parameters and execute it.

> - get some statistics of its performance: how many staments are found and

how

> many compiled?

If you re-execute the statement, it's always recompiled. See above.

> - to "pin" some statements permanently in the buffer: the issue is that
> "lexical SQL" (kind of "select .. where name='john' ") is wasting space of
> any buffer by forcing "good SQL" statements out of it. In that light is

makes

> sense to tell RDBMS that some statements have to be in the buffer
> permanently, e.g. those executed 10x per second. Well, this is impossible
> probably as the buffer is not shared between connections.

See above.

With regards,

Martijn Tonies
Database Workbench - developer tool for InterBase, Firebird, MySQL & MS SQL
Server.
Upscene Productions
http://www.upscene.com