Re: Really really slow select count(*)

From: "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>
To: <sthomas(at)peak6(dot)com>,"Maciek Sakrejda" <msakrejda(at)truviso(dot)com>
Cc: "felix" <crucialfelix(at)gmail(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: Really really slow select count(*)
Date: 2011-02-08 16:36:09
Message-ID: 4D511C99020000250003A62D@gw.wicourts.gov
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Maciek Sakrejda <msakrejda(at)truviso(dot)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

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Marti Raudsepp 2011-02-08 16:50:23 Re: Really really slow select count(*)
Previous Message Maciek Sakrejda 2011-02-08 16:23:25 Re: Really really slow select count(*)