Received: from maia.hub.org (maia-5.hub.org [200.46.204.29])
	by mail.postgresql.org (Postfix) with ESMTP id B06EF1337B96
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Thu,  3 Feb 2011 21:28:22 -0400 (AST)
Received: from mail.postgresql.org ([200.46.204.86])
	by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024)
	with ESMTP id 57053-05
	for <pgsql-performance-postgresql.org@mail.postgresql.org>;
	Fri,  4 Feb 2011 01:28:16 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.catalyst.net.nz (bertrand.catalyst.net.nz [202.78.240.40])
	by mail.postgresql.org (Postfix) with ESMTP id 2C4A0133740B
	for <pgsql-performance@postgresql.org>;
	Thu,  3 Feb 2011 21:28:12 -0400 (AST)
Received: from localhost (localhost [127.0.0.1])
	by mail.catalyst.net.nz (Postfix) with ESMTP id 9374431D4A
	for <pgsql-performance@postgresql.org>;
	Fri,  4 Feb 2011 14:28:10 +1300 (NZDT)
X-Virus-Scanned: Debian amavisd-new at catalyst.net.nz
Received: from mail.catalyst.net.nz ([127.0.0.1])
	by localhost (bertrand.catalyst.net.nz [127.0.0.1]) (amavisd-new,
	port 10024)
	with ESMTP id zkZbwL-zujIF for <pgsql-performance@postgresql.org>;
	Fri,  4 Feb 2011 14:28:10 +1300 (NZDT)
Received: from [192.168.1.11] (122-60-64-230.jetstream.xtra.co.nz
	[122.60.64.230]) (Authenticated sender: mark.kirkwood)
	by mail.catalyst.net.nz (Postfix) with ESMTPSA id B9AA8322B9
	for <pgsql-performance@postgresql.org>;
	Fri,  4 Feb 2011 14:28:09 +1300 (NZDT)
Message-ID: <4D4B5628.8030100@catalyst.net.nz>
Date: Fri, 04 Feb 2011 14:28:08 +1300
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7
MIME-Version: 1.0
To: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] Slow count(*) again...
References: <201102012247.p11Ml6u02682@momjian.us>
	<4D48914B.4050403@dunslane.net>	<4D489AD1.1010105@vmsinfo.com>
	<AANLkTiknZi97dDwm7sHqy0EL7tpNEP9sY5uPV6AN+q=u@mail.gmail.com>
	<4D499E55.4020107@vmsinfo.com> <4D49A6B9.4060608@2ndquadrant.com>
	<4D49C482.4010707@vmsinfo.com> <4D49F0BA.9000901@2ndquadrant.com>
	<4D4A16BF.1020304@vmsinfo.com> <4D4A4844.3020409@2ndquadrant.com>
	<4D4AD9F6.6040903@vmsinfo.com> <4D4AE16E.9040807@peak6.com>
	<4D4B17B4.9030406@vmsinfo.com> <4D4B235C.1080308@catalyst.net.nz>
	<4D4B4D30.2060007@wizmail.org>
In-Reply-To: <4D4B4D30.2060007@wizmail.org>
Content-Type: multipart/alternative;
	boundary="------------000306040500080609010007"
X-Virus-Scanned: Maia Mailguard 1.0.1
X-Spam-Status: No, hits=-1.909 tagged_above=-10 required=5
	tests=BAYES_00=-1.9, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01
X-Spam-Level: 
X-Archive-Number: 201102/145
X-Sequence-Number: 42283

This is a multi-part message in MIME format.
--------------000306040500080609010007
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 04/02/11 13:49, Jeremy Harris wrote:
> On 2011-02-03 21:51, Mark Kirkwood wrote:
>> The cases I've seen in production typically involve "outgrowing" 
>> optimizer parameter settings: (e.g work_mem, effective_cache_size) as 
>> the application dataset gets bigger over time.
>
> An argument in favour of the DBMS maintaining a running estimate of 
> such things.

That is an interesting idea - I'm not quite sure how it could apply to 
server config settings (e.g work_mem) for which it would be dangerous to 
allow the server to increase on the fly, but it sure would be handy to 
have some sort of query execution "memory" so that alerts like:

"STATEMENT: SELECT blah  : PARAMETERS blah: using temp file(s), last 
execution used memory"

could be generated (this could be quite complex I guess, requiring some 
sort of long lived statement plan cache).

Cheers

Mark

--------------000306040500080609010007
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body text="#000000" bgcolor="#ffffff">
    On 04/02/11 13:49, Jeremy Harris wrote:
    <blockquote cite="mid:4D4B4D30.2060007@wizmail.org" type="cite">On
      2011-02-03 21:51, Mark Kirkwood wrote:
      <br>
      <blockquote type="cite">The cases I've seen in production
        typically involve "outgrowing" optimizer parameter settings:
        (e.g work_mem, effective_cache_size) as the application dataset
        gets bigger over time.
        <br>
      </blockquote>
      <br>
      An argument in favour of the DBMS maintaining a running estimate
      of such things.
      <br>
    </blockquote>
    <font size="-1"><font face="Helvetica"><br>
        That is an interesting idea - I'm not quite sure how it could
        apply to server config settings (e.g work_mem) for which it
        would be dangerous to allow the server to increase on the fly,
        but it sure would be handy to have some sort of query execution
        "memory" so that alerts like:<br>
        <br>
        "STATEMENT: SELECT blah&nbsp; : PARAMETERS blah: using temp file(s),
        last execution used memory"<br>
        <br>
        could be generated (this could be quite complex I guess,
        requiring some sort of long lived statement plan cache).<br>
        <br>
        Cheers<br>
        <br>
        Mark<br>
      </font></font>
  </body>
</html>

--------------000306040500080609010007--