Re: Really really slow select count(*)

Поиск
Список
Период
Сортировка
От Kevin Grittner
Тема Re: Really really slow select count(*)
Дата
Msg-id 4D511C99020000250003A62D@gw.wicourts.gov
обсуждение исходный текст
Ответ на Re: Really really slow select count(*)  (Maciek Sakrejda <msakrejda@truviso.com>)
Ответы Re: Really really slow select count(*)  (Marti Raudsepp <marti@juffo.org>)
Список pgsql-performance
Maciek Sakrejda <msakrejda@truviso.com> wrote:
>>> Well.... it said "Failed to shutdown ..............."  and then
>>> returned control. and then proceeded to run for about an hour.
>>> I'm not sure how graceful that is.
>>
>> Ah, but that was just the control script that sends the database
>> the command to shut down. The 'graceful' part, is that the
>> database is being nice to everyone trying to do things with the
>> data inside.
>>
>> The control script has a timeout. So it'll send the command, wait
>> a few seconds to see if the database responds, and then gives up.
>
> For what it's worth, I think that's the not-so-graceful part. The
> control script gives up, but the actual shutdown still occurs
> eventually, after all current connections have ended. I think most
> users will take pg_ctl at its word, and assume "Failed to
> shutdown" means "I couldn't shut down with this command, maybe you
> should try something else", and not "I couldn't shut down right
> now, although I'll get to it as soon as everyone disconnects.".

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.

In my world, telling PostgreSQL to shut down PostgreSQL is most
often because in a few minutes someone is going to pull the plug to
move the server, an electrician is going to flip the circuit off to
do some wiring, or (in one recent event) the building is on fire and
the fire department is about to cut electrical power.  In such
situations, patiently waiting for a long-running query to complete
is a Very Bad Idea, much less waiting for a connection pool to cycle
all connections out.  Telling the user that the shutdown failed,
when what is really happening is that it will block new connections
and keep waiting around indefinitely, with an actual shutdown at
some ill-defined future moment is adding insult to injury.

In my view, anyway....

-Kevin

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

Предыдущее
От: Maciek Sakrejda
Дата:
Сообщение: Re: Really really slow select count(*)
Следующее
От: Marti Raudsepp
Дата:
Сообщение: Re: Really really slow select count(*)