From: Jim C. Nasby <jnasby@pervasive.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Markus Schaber <schabi@logix-tt.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: merge>hash>loop
Date: Tue, 18 Apr 2006 18:22:26 -0500
Message-ID: <20060418232226.GO49405@pervasive.com> (raw)
In-Reply-To: <19433.1145399208@sss.pgh.pa.us>
References: <1145029009.3422.31.camel@spectre.intellivid.com>
<10000.1145031205@sss.pgh.pa.us>
<1145033149.3422.41.camel@spectre.intellivid.com>
<11035.1145033929@sss.pgh.pa.us>
<4444C4CF.2000106@logix-tt.com>
<19433.1145399208@sss.pgh.pa.us>
On Tue, Apr 18, 2006 at 06:26:48PM -0400, Tom Lane wrote:
> Markus Schaber <schabi@logix-tt.com> writes:
> > Hmm, how does effective_cach_size correspond with it? Shouldn't a high
> > effective_cache_size have a similar effect?
>
> It seems reasonable to suppose that effective_cache_size ought to be
> used as a number indicating how much "stuff" would hang around from
> query to query. Right now it's not used that way...
Maybe it would be a reasonable first pass to have estimators calculate
the cost if a node found everything it wanted in cache and then do a
linear interpolation between that and the costs we currently come up
with? Something like pg_class.relpages / sum(pg_class.relpages) would
give an idea of how much of a relation is likely to be cached, which
could be used for the linear interpolation.
Of course having *any* idea as to how much of a relation was actually in
shared_buffers (or better yet, the OS cache) would be a lot more
accurate, but this simple method might be a good enough first-pass.
--
Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
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: jnasby@pervasive.com, tgl@sss.pgh.pa.us, schabi@logix-tt.com
Subject: Re: merge>hash>loop
In-Reply-To: <20060418232226.GO49405@pervasive.com>
* 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