From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Greg Stark <stark(at)mit(dot)edu>, Billy Earney <billy(dot)earney(at)gmail(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: query cache |
Date: | 2012-03-30 00:54:25 |
Message-ID: | CA+TgmoZUJaqSkE5BxzJG0_nvh49Z=6DrxNWRN=j7vnUmua=SjQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Mar 29, 2012 at 4:57 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> It's also probably worth keeping in mind the next time we
>> bump the protocol version: it would be nice to have a way of doing
>> prepare-bind-execute in a single protocol message, which I believe to
>> be not possible at present.
>
> Huh? That's the standard way of doing it, actually. You send
> Prepare/Bind/Execute/Sync in one packet, and wait for results.
That precludes some optimizations, like doing the whole thing under
the same snapshot, since you don't know for sure when the Execute will
be sent. And as a practical matter, it's slower. So there's some
room for improvement there, any way you slice it.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
From | Date | Subject | |
---|---|---|---|
Next Message | Dobes Vandermeer | 2012-03-30 01:25:39 | Re: HTTP Frontend? (and a brief thought on materialized views) |
Previous Message | Tom Lane | 2012-03-29 22:56:30 | Re: Speed dblink using alternate libpq tuple storage |