Re: changing MyDatabaseId
От
Robert Haas
Тема
Re: changing MyDatabaseId
Дата
Msg-id
AANLkTikoxyXNx2Ao_23G_tYSsksC1PvKXY7wfoFJ1MXt@mail.gmail.com
Ответ на
Re: changing MyDatabaseId (Greg Stark)
Список
Дерево обсуждения
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 по дате отправления
От: Tom Lane
Дата: