Re: merge>hash>loop
От
Jim C. Nasby
Тема
Re: merge>hash>loop
Дата
Msg-id
20060418232226.GO49405@pervasive.com
Ответ на
Re: merge>hash>loop (Tom Lane)
Список
Дерево обсуждения
merge>hash>loop Ian Westmacott <ianw@intellivid.com>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
Re: merge>hash>loop Ian Westmacott <ianw@intellivid.com>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
Re: merge>hash>loop Markus Schaber <schabi@logix-tt.com>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
Re: merge>hash>loop "Jim C. Nasby" <jnasby@pervasive.com>
Re: merge>hash>loop "Jim C. Nasby" <jnasby@pervasive.com>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
Re: merge>hash>loop "Jim C. Nasby" <jnasby@pervasive.com>
Re: merge>hash>loop Mark Kirkwood <markir@paradise.net.nz>
Re: merge>hash>loop "Jim C. Nasby" <jnasby@pervasive.com>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
Re: merge>hash>loop "Jim C. Nasby" <jnasby@pervasive.com>
Re: merge>hash>loop Mark Kirkwood <markir@paradise.net.nz>
Re: merge>hash>loop Tom Lane <tgl@sss.pgh.pa.us>
On Tue, Apr 18, 2006 at 06:26:48PM -0400, Tom Lane wrote: > Markus Schaber 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
В списке pgsql-performance по дате отправления