From: | "Jim C(dot) Nasby" <jnasby(at)pervasive(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Markus Schaber <schabi(at)logix-tt(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: merge>hash>loop |
Date: | 2006-04-18 23:22:26 |
Message-ID: | 20060418232226.GO49405@pervasive.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Tue, Apr 18, 2006 at 06:26:48PM -0400, Tom Lane wrote:
> Markus Schaber <schabi(at)logix-tt(dot)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(at)pervasive(dot)com
Pervasive Software http://pervasive.com work: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-18 23:38:33 | Re: merge>hash>loop |
Previous Message | Jim C. Nasby | 2006-04-18 23:15:52 | Re: merge>hash>loop |