From: | Neil Conway <neilc(at)samurai(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Joachim Wieland <joe(at)mcknight(dot)de>, pgsql-patches(at)postgresql(dot)org |
Subject: | Re: TODO item: list prepared queries |
Date: | 2006-01-02 21:34:48 |
Message-ID: | 43B99C78.7070402@samurai.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-patches |
Tom Lane wrote:
> I object VERY strongly to the part of the patch that inserts a
> deparse_query_list() call into exec_parse_message(). That is not a
> cheap operation, and imposing that sort of overhead on every Parse
> message is entirely unacceptable from a performance point of view.
Well, it doesn't insert a deparse_query_list() into the processing of
*every* Parse message -- it only does so for Parse messages that create
named prepared statements. I don't see that there is a fundamental
difference between a named Parse and an SQL-level PREPARE: if adding
deparse_query_list() to one is too expensive, ISTM it is too expensive
for either.
> I see no need for it either. What's wrong with regurgitating the
> original source string, which is already saved in prepared queries?
It is inconsistent to use the string supplied by the client for
protocol-level prepared statements, but to use the SQL produced by
deparsing for SQL PREPARE.
One possibility would be to execute deparse_query_list() in the SRF
(which is what Joachim's patch did originally), but that is fragile: if
a table a prepared statement depends on is dropped, the view will be
broken. We could workaround that by enclosing the deparse_query_list()
call in a PG_TRY block (and displaying a NULL query string for broken
prepared statements), but that doesn't prevent more subtle problems like
the search_path changing.
-Neil
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-01-02 21:40:19 | Re: TODO item: list prepared queries |
Previous Message | Qingqing Zhou | 2006-01-02 21:03:20 | Re: Stats collector performance improvement |