| From: | Marti Raudsepp <marti(at)juffo(dot)org> |
|---|---|
| To: | Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov> |
| Cc: | sthomas(at)peak6(dot)com, Maciek Sakrejda <msakrejda(at)truviso(dot)com>, 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:50:23 |
| Message-ID: | AANLkTi=uh-zScT=LcYQ6kXDXCpmMZoAeiO4hqk0=WWSt@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Tue, Feb 8, 2011 at 18:36, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Sylvain Rabot | 2011-02-08 17:30:25 | Re: Indexes with condition using immutable functions applied to column not used |
| Previous Message | Kevin Grittner | 2011-02-08 16:36:09 | Re: Really really slow select count(*) |