Re: Prepared Statements vs. pgbouncer
От | Paul Lindner |
---|---|
Тема | Re: Prepared Statements vs. pgbouncer |
Дата | |
Msg-id | 20071001081720.GM3140@inuus.com обсуждение исходный текст |
Ответ на | Re: Prepared Statements vs. pgbouncer (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: Prepared Statements vs. pgbouncer
|
Список | pgsql-jdbc |
On Sun, Sep 30, 2007 at 08:11:04PM +1300, Oliver Jowett wrote: > Paul Lindner wrote: > > >2) If we try to prepare a statement with an hashed name and it already > > exists then we ignore the error and continue. > > Errors will cause the current transaction to fail.. Looking through the backend code and the protocol flow documenation it appears we could just close the statement name and it won't cause an error: switch (close_type) { case 'S': if (close_target[0] != '\0') DropPreparedStatement(close_target, false); else where void DropPreparedStatement(const char *stmt_name, bool showError) So amend number 2 to say: 2) Before preparing a statement with a hashed name, send a close statement to insure that we don't get an error inside of a transaction. This is just as performant as the current driver which will happily re-prepare the same SQL many times. Sadly it appears that the protocol does not allow for arbitrary optional data to be sent along with the query. For example, it would be fairly easy to modify gram.y to support IF EXISTS or OR REPLACE -- getting that into the protocol looks to be a bit more difficult. (FYI if anyone is interested in the following syntax let me know, If there's interest I could spend some of my free time hacking the backend) DEALLOCATE [IF EXISTS] <plan_name>; PREPARE [OR REPLACE] <plan_name> [(args, ...)] AS <query> > >3) If we receive an error while executing a prepared statement with an > > hashed name the driver will try to re-prepare the statement and > > re-execute the query. If an error occurs after this retry step then > > error are surfaced to the caller. > > ... so you can't just back off and try again. Actually #3 isn't needed anymore if the deallocate/re-prepare steps are carried out as mentioned above. For me it still appears worth the effort to modify the driver to support what I've outlined. I do hope that you'll find any work done useful for general consumption. -- Paul Lindner ||||| | | | | | | | | | lindner@inuus.com
Вложения
В списке pgsql-jdbc по дате отправления: