Re: Really really slow select count(*)

From: Marti Raudsepp <marti(at)juffo(dot)org>
To: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
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-07 10:30:25
Message-ID: AANLkTi=TO=pCTgbWfJzHmmtbrY-sWi6nYG2e-5Kyhxdp@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On Mon, Feb 7, 2011 at 05:03, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au> wrote:
> What would possibly help would be if Pg could fall back to lower
> shared_buffers automatically, screaming about it in the logs but still
> launching. OTOH, many people don't check the logs, so they'd think their
> new setting had taken effect and it hadn't - you've traded one usability
> problem for another. Even if Pg issued WARNING messages to each client
> that connected, lots of (non-psql) clients don't display them, so many
> users would never know.
>
> Do you have a suggestion about how to do this better? The current
> approach is known to be rather unlovely, but nobody's come up with a
> better one that works reasonably and doesn't trample on other System V
> shared memory users that may exist on the system.

We could do something similar to what Apache does -- provide distros
with a binary to check the configuration file in advance. This check
program is launched before the "restart" command, and if it fails, the
server is not restarted.

Regards,
Marti

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Marti Raudsepp 2011-02-07 10:47:26 Re: Different execution plans for semantically equivalent queries
Previous Message Vitalii Tymchyshyn 2011-02-07 10:02:57 Re: getting the most of out multi-core systems for repeated complex SELECT statements