Re: changing MyDatabaseId

Поиск
Список
Период
Сортировка
Искать
От
Robert Haas
Тема
Re: changing MyDatabaseId
Дата
Msg-id
AANLkTikoxyXNx2Ao_23G_tYSsksC1PvKXY7wfoFJ1MXt@mail.gmail.com
Ответ на
Список
Дерево обсуждения
changing MyDatabaseId Robert Haas <robertmhaas@gmail.com>
Re: changing MyDatabaseId Tom Lane <tgl@sss.pgh.pa.us>
Re: changing MyDatabaseId Alvaro Herrera <alvherre@commandprompt.com>
Re: changing MyDatabaseId Bruce Momjian <bruce@momjian.us>
Re: changing MyDatabaseId Robert Haas <robertmhaas@gmail.com>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Alvaro Herrera <alvherre@commandprompt.com>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Alvaro Herrera <alvherre@commandprompt.com>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Tom Lane <tgl@sss.pgh.pa.us>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Andres Freund <andres@anarazel.de>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Andres Freund <andres@anarazel.de>
Re: changing MyDatabaseId Markus Wanner <markus@bluegap.ch>
Re: changing MyDatabaseId Robert Haas <robertmhaas@gmail.com>
Re: changing MyDatabaseId Greg Stark <gsstark@mit.edu>
Re: changing MyDatabaseId Robert Haas <robertmhaas@gmail.com>
Re: changing MyDatabaseId Greg Stark <gsstark@mit.edu>
On Wed, Nov 17, 2010 at 12:42 PM, Greg Stark  wrote:
> On Wed, Nov 17, 2010 at 4:52 PM, Robert Haas  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

В списке pgsql-hackers по дате отправления
От: Heikki Linnakangas
Дата:
Сообщение: Re: unlogged tables
От: Tom Lane
Дата:
FAQ