Re: Really really slow select count(*) - Mailing list pgsql-performance

From Ross J. Reedstrom
Subject Re: Really really slow select count(*)
Date
Msg-id 20110216162832.GA17015@rice.edu
Whole thread Raw
In response to Re: Really really slow select count(*)  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: Really really slow select count(*)
List pgsql-performance
On Tue, Feb 08, 2011 at 03:52:31PM -0600, Kevin Grittner wrote:
> Scott Marlowe <scott.marlowe@gmail.com> wrote:
> > Greg Smith <greg@2ndquadrant.com> wrote:
>
> >> Kevin and I both suggested a "fast plus timeout then immediate"
> >> behavior is what many users seem to want.
>
> > Are there any settings in postgresql.conf that would make it
> > unsafe to use -m immediate?
>
> I don't think so.  There could definitely be problems if someone
> cuts power before your shutdown completes, though.  (I hear that
> those firefighters like to cut power to a building before they grab
> those big brass nozzles to spray a stream of water into a building.
> Go figure...)

Following you off topic, I know of one admin type who has stated "I don't
care what sort of fine the power company wants to give me, if my
property's on fire, I'm going to pull the meter, in order to hand it to
the first responder, rather than have them sit there waiting for the
power tech to arrive while my house burns."

Back on topic, I like the the idea of a timed escalation. That means
there's two things to configure though, timeout(s?) and the set of
states to escalate through. I can see different use cases for different
sets. Hmmm:

pg_ctl -m s:10:f:5:i restart

for smart, 5 sec. timeout, escalate to fast, 5 sec., then immediate?
Not sure how rhat would interact w/ -t.

Perhaps:

pg_ctl -t 10 -m s -t 5 -m f -m i restart

Some video-processing tools do things like that: the order of options
impacts their interaction.

Ross
--
Ross Reedstrom, Ph.D.                                 reedstrm@rice.edu
Systems Engineer & Admin, Research Scientist        phone: 713-348-6166
Connexions                  http://cnx.org            fax: 713-348-3665
Rice University MS-375, Houston, TX 77005
GPG Key fingerprint = F023 82C8 9B0E 2CC6 0D8E  F888 D3AE 810E 88F0 BEDE




pgsql-performance by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: high user cpu, massive SELECTs, no io waiting problem
Next
From: Thomas Pöhler
Date:
Subject: Re: high user cpu, massive SELECTs, no io waiting problem