From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
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-29 20:57:37 |
Message-ID: | 13050.1333054657@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> Interestingly, Peter Geoghegan's blog post on the pg_stat_statements
> patch you just committed[1] claims that the overhead of fingerprinting
> queries was only 1-2.5%, which is less than I would have thought, so
> if we ever get to the point where we're fairly sure we've got problem
> three licked, it might make sense to revisit this due to problems one
> and two.
Maybe.
> 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.
This requires that you understand the query well enough to perform
Bind without seeing a Describe result, but that seems essential
to any one-round-trip case anyway. It's not the protocol design
that is holding back anybody who wants to do that.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Dimitri Fontaine | 2012-03-29 21:10:51 | Re: Command Triggers patch v18 |
Previous Message | Dimitri Fontaine | 2012-03-29 20:21:36 | Re: Command Triggers patch v18 |