Re: Really really slow select count(*)
От | Scott Marlowe |
---|---|
Тема | Re: Really really slow select count(*) |
Дата | |
Msg-id | AANLkTikbcwmjvnzdDodfyu_y1jckp9rHw4MaWmNyaUQw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Really really slow select count(*) (Marti Raudsepp <marti@juffo.org>) |
Ответы |
Re: Really really slow select count(*)
|
Список | pgsql-performance |
On Tue, Feb 8, 2011 at 9:50 AM, Marti Raudsepp <marti@juffo.org> wrote: > On Tue, Feb 8, 2011 at 18:36, Kevin Grittner > <Kevin.Grittner@wicourts.gov> wrote: >> Yeah, current behavior with that shutdown option is the opposite of >> smart for any production environment I've seen. (I can see where it >> would be handy in development, though.) What's best in production >> is the equivalent of the fast option with escalation to immediate if >> necessary to ensure shutdown within the time limit. > > +1, we should call it "dumb" :) > > Not accepting new connections with "the database system is shutting > down" makes it even worse -- it means you can't log in to the server > to inspect who's querying it or call pg_terminate_backend() on them. > > I couldn't find any past discussions about changing the default to "fast". > Are there any reasons why that cannot be done in a future release? Or at least throw a hint the user's way that -m fast might be needed.
В списке pgsql-performance по дате отправления: