Re: Estimating seq_page_fetch and random_page_fetch

From: Martijn van Oosterhout <kleptog(at)svana(dot)org>
To: Umar Farooq Minhas <umarfm13(at)hotmail(dot)com>
Cc: pgsql-hackers(at)postgresql(dot)org, Luke Lonergan <LLonergan(at)greenplum(dot)com>, Gregory Stark <stark(at)enterprisedb(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Ayush Parashar <aparashar(at)greenplum(dot)com>, jim(at)nasby(dot)net, neilc(at)samurai(dot)com
Subject: Re: Estimating seq_page_fetch and random_page_fetch
Date: 2007-03-09 15:01:47
Message-ID: 20070309150147.GB7358@svana.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Mar 08, 2007 at 07:01:17PM -0500, Umar Farooq Minhas wrote:
> displayed, I want cpu cost and io cost displayed separated when i run
> EXPLAIN on a particular query. Till now I haven't been able to figure
> out a 'clean' way of doing this. Can anyone tell me how much time
> should I expect to spend making such a change ? and from where should
> I start ? costsize.c ?

That's going to be a lot of work. You need to duplicate the variable
and eery usage of that variable. And I can't imagine why you'd be
interested anyway...

> I have another question. Looking at the optimizer code, it pretty
> much looks insensitive to the memory factor. The only parameters
> being utilized are the "effective_cache_size" ( in estimating index
> cost only) and "work_mem" for (sort, aggregation, groups, hash/merge
> joins). Are these the only memory factors that DIRECTLY effect the
> cost estimates of the planner/optimizer?

Sure, what other factors were you considering?

Have a nice day,
--
Martijn van Oosterhout <kleptog(at)svana(dot)org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Heikki Linnakangas 2007-03-09 15:10:25 Re: CLUSTER and MVCC
Previous Message Martijn van Oosterhout 2007-03-09 14:54:01 Re: Calculated view fields (8.1 != 8.2)