Re: Really really slow select count(*)

Поиск
Список
Период
Сортировка
От Marti Raudsepp
Тема Re: Really really slow select count(*)
Дата
Msg-id AANLkTi=uh-zScT=LcYQ6kXDXCpmMZoAeiO4hqk0=WWSt@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Really really slow select count(*)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Ответы Re: Really really slow select count(*)  (Scott Marlowe <scott.marlowe@gmail.com>)
Re: Really really slow select count(*)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Re: Really really slow select count(*)  (Greg Smith <greg@2ndquadrant.com>)
Список pgsql-performance
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?

Regards,
Marti

В списке pgsql-performance по дате отправления:

Предыдущее
От: "Kevin Grittner"
Дата:
Сообщение: Re: Really really slow select count(*)
Следующее
От: Sylvain Rabot
Дата:
Сообщение: Re: Indexes with condition using immutable functions applied to column not used