pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed

From: Jeremy Harris <jgh@wizmail.org>
To: pgsql-performance@postgresql.org
Subject: Re: [HACKERS] Slow count(*) again...
Date: Fri, 04 Feb 2011 00:49:52 +0000
Message-ID: <4D4B4D30.2060007@wizmail.org> (raw)
In-Reply-To: <4D4B235C.1080308@catalyst.net.nz>
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>

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.
-- 
Jeremy

view thread (246+ messages)  latest in thread

Message-ID: <4D4B4D30.2060007@wizmail.org>
Permalink:  ../4D4B4D30.2060007@wizmail.org/
Also on:    postgresql.org/message-id/4D4B4D30.2060007@wizmail.org

copy link · copy postgr.es

reply

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Reply to all the recipients using the --to and --cc options:
  reply via email

  To: pgsql-performance@postgresql.org
  Cc: jgh@wizmail.org
  Subject: Re: [HACKERS] Slow count(*) again...
  In-Reply-To: <4D4B4D30.2060007@wizmail.org>

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox