From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
---|---|
To: | Oliver Jowett <oliver(at)opencloud(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, John Lister <john(dot)lister-ps(at)kickstone(dot)com>, pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Query preparation |
Date: | 2009-04-16 11:12:06 |
Message-ID: | 49E71286.9020500@enterprisedb.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
Tom Lane wrote:
> Oliver Jowett <oliver(at)opencloud(dot)com> writes:
>> Heikki Linnakangas wrote:
>>> Does anyone see a problem with caching the result set descriptor
>>> (RowDescription)? AFAICS it should never change after a statement is
>>> prepared. If not, I'll polish up and submit the patch.
>
>> If you tie it to the existing named statement mechanisms I think that
>> works. We invalidate the named statement anyway if the parameter types
>> change, and you want to invalidate any cached row description at the
>> same time. Schema changes could bite you, but I think they bite named
>> statements in other ways anyway. (Not sure how far the server-side
>> efforts to do plan invalidation progressed)
>
> It should be safe. The server is set up to throw an error if you try to
> re-use a prepared statement whose output tuple descriptor would have
> changed due to schema changes. So there's a backstop if the driver's
> invalidation logic misses anything.
Here's the patch. Describe message is only sent in the first invocation
of a query. The Field[] array constructed from the RowDescription
message is saved in the SimpleQuery object for reuse.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
Attachment | Content-Type | Size |
---|---|---|
avoid-repeating-portal-describes-2.patch | text/x-diff | 8.6 KB |
From | Date | Subject | |
---|---|---|---|
Next Message | John Lister | 2009-04-16 11:26:25 | Re: Query preparation |
Previous Message | bdbusch | 2009-04-15 21:33:54 | Re: Deadlock detection |