On Wed, Nov 17, 2010 at 12:42 PM, Greg Stark <gsstark@mit.edu> wrote:
> On Wed, Nov 17, 2010 at 4:52 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> However, that test doesn't capture everything. For example, imagine a
>> connection pooler sitting in front of PG. Rebinding to a new database
>> means disconnecting a TCP connection and establishing a new one.
>> Switching databases might save some latency there even if we don't
>> actually save much in terms of CPU instructions. Maybe that's not
>> important, though. I don't know. I don't want to let my theorizing
>> get too far ahead of the data.
>
> Everything you said is true but there's more. A freshly created
> backend needs to build relcache entries and for every relation in your
> query. A reused connection eventually warms up the relcache and
> syscaches and can plan new queries using them without doing any
> syscalls. And of course if it's a query that's already been planned
> might be able to reuse the entire plan structure without replanning
> it.
I think you're missing the point. If we switch databases, all cached
relations and plans have to be flushed anyway. We're talking about
what might NOT need to be flushed on switching databases.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
