Re: Really really slow select count(*)

From: Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com>
To: Marti Raudsepp <marti(at)juffo(dot)org>
Cc: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, 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 17:31:25
Message-ID: AANLkTikbcwmjvnzdDodfyu_y1jckp9rHw4MaWmNyaUQw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Tue, Feb 8, 2011 at 9:50 AM, Marti Raudsepp <marti(at)juffo(dot)org> wrote:
> 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?

Or at least throw a hint the user's way that -m fast might be needed.

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Maciek Sakrejda 2011-02-08 17:58:27 Re: Really really slow select count(*)
Previous Message Sylvain Rabot 2011-02-08 17:30:25 Re: Indexes with condition using immutable functions applied to column not used