From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | Greg Stark <gsstark(at)mit(dot)edu>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Kevin Grittner" <Kevin(dot)Grittner(at)wicourts(dot)gov>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: A costing analysis tool |
Date: | 2005-10-16 21:53:40 |
Message-ID: | 87d5m5dt7f.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Josh Berkus <josh(at)agliodbs(dot)com> writes:
> Greg,
>
> > Or something like that. It might require breaking random_page_cost into two
> > or three different parameters that would normally have the same cost but
> > aren't handled the same, like random_heap_cost, random_leaf_cost, and
> > random_nonleaf_cost.
>
> Gods forbid. People don't know how to use random_page_cost as it is; how are
> they going to handle having 5 different parameters?
Well I wasn't anticipating actually exposing each of these parameters as
separate guv variables. I was anticipating having each of them have the same
cost, but possibly be treated differently by outer plan nodes. For instance a
nested loop iterating an inner node 100 times with those three costs estimated
at <20,15,10> instead of calculating estimated cost of <2000,1500,1000> it can
calculate <2000,150,10> -- discounting leaf page accesses by 90% and nonleaf
pages by 99% but not discounting heap accesses at all.
When the time comes to calculating a single total cost (either for the final
plan to display with EXPLAIN or for a decision picking between alternate
plans) all three might be costed equally using a single random_page_cost guc.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-10-16 22:21:37 | libpq's pollution of application namespace |
Previous Message | Neil Conway | 2005-10-16 21:51:04 | Re: PostgreSQL roadmap for 8.2 and beyond. |