Re: query cache

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

In response to

Responses

Browse pgsql-hackers by date

  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