Re: Source Code Help Needed
От | Vikram Kalsi |
---|---|
Тема | Re: Source Code Help Needed |
Дата | |
Msg-id | ed5f0fd7050603002551a4b897@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Source Code Help Needed (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Source Code Help Needed
(Tom Lane <tgl@sss.pgh.pa.us>)
|
Список | pgsql-hackers |
Tom, Thanks a ton again, and, here's another problem that has me really puzzled-<br /><br />I'm starting with a fresh installof pgsql-8.0.1, and make 3 changes-<br /><br />1.) src/include/nodes/relation.h, Add a new Variable, hutz_idx_benefitto IndexOptInfo <br /><br />typedef struct IndexOptInfo<br />{..............<br />/* Per IndexScan benefit,More than 1 indexscan maybe used for 1 tablescan ex. w/ OR */<br /><span style="color: rgb(255, 0, 0);">Cost hutz_idx_benefit;</span><br/>..............} IndexOptInfo; <br /><br /><br />2.) src/backend/optimizer/path/costsize.c,cost_index(), assign value to index->hutz_idx_benefit<br /><br />run_cost += indexTotalCost- indexStartupCost;<br /><span style="color: rgb(255, 0, 0);">index->hutz_idx_benefit = run_cost; </span><br/><span style="color: rgb(51, 51, 255);">elog(NOTICE,"cost_index():index->indexoid=%u index->hutz_idx_benefit=%.2f",index->indexoid, index->hutz_idx_benefit);</span><br /><br /><br />3.) src/backend/optimizer/path/orindxpath.c,best_or_subclause_indexes(), Read the value(s) of index->indexoid and index->hutz_idx_benefit<br/><br />/* Gather info for each OR subclause */<br />foreach(slist, subclauses)<br />{...................<br/>infos = lappend(infos, best_indexinfo);<br />...................} <br /><br />/<span style="color:rgb(255, 0, 0);">* DEBUG */</span><br style="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);">ListCell *l;</span><br style="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);"> int count=0;</span><brstyle="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);">foreach(l, infos)</span><br style="color:rgb(255, 0, 0);" /><span style="color: rgb(255, 0, 0);">{</span><br style="color: rgb(255, 0, 0);" /><span style="color:rgb(255, 0, 0);">IndexOptInfo *index = (IndexOptInfo *) lfirst(l);</span><br style="color: rgb(255, 0, 0);"/><span style="color: rgb(51, 51, 255);">elog(NOTICE,"best_or_subclause_indexes():infos c=%i: indexoid=%u hutz_idx_benefit=%.2f",count, index->indexoid, index->hutz_idx_benefit);</span><br style="color: rgb(255, 0, 0);" /><spanstyle="color: rgb(255, 0, 0);">count++;</span><br style="color: rgb(255, 0, 0);" /><span style="color: rgb(255, 0,0);">}</span><br />................... <br /> pathnode->indexinfo = infos; /* indexinfo' is a list of IndexOptInfo nodes,one per scan to be performed */<br /><br /><br />So, basically I have added a new variable alongside indexoid whichis the run_cost of one of the index scans if there are multiple index scans such as in the case of OR subclauses for1 table.<br /> Now, I do a complete build and run two queries with OR subclauses as follows-<br /><br /> tpcd=# selects_suppkey from supplier where (s_suppkey>125 and s_suppkey<128) or (s_suppkey>175 and s_suppkey<185) or(s_suppkey>200 and s_suppkey<215);<br /> NOTICE: cost_index():index->indexoid=186970 index->hutz_idx_benefit=2.02<br/> NOTICE: cost_index():index->indexoid=186970 index->hutz_idx_benefit=2.06<br />NOTICE: cost_index():index->indexoid=186970 index->hutz_idx_benefit=<span style="color: rgb(204, 0, 0); font-weight:bold;">2.09</span><br /> NOTICE: best_or_subclause_indexes():infos c=0: indexoid=186970 hutz_idx_benefit=<spanstyle="font-weight: bold; color: rgb(204, 0, 0);">2.09</span><br /> NOTICE: best_or_subclause_indexes():infosc=1: indexoid=186970 hutz_idx_benefit=<span style="font-weight: bold; color: rgb(204, 0,0);">2.09</span><br /> NOTICE: best_or_subclause_indexes():infos c=2: indexoid=186970 hutz_idx_benefit=<span style="font-weight:bold; color: rgb(204, 0, 0);">2.09</span><br /><br />On the second occasion, I change the order of theOR subclauses...<br /><br /> tpcd=# select s_suppkey from supplier where (s_suppkey>200 and s_suppkey<215) or (s_suppkey>175and s_suppkey<185) or (s_suppkey>125 and s_suppkey<128);<br /> NOTICE: cost_index():index->indexoid=186970index->hutz_idx_benefit=2.09<br /> NOTICE: cost_index():index->indexoid=186970index->hutz_idx_benefit=2.06<br /> NOTICE: cost_index():index->indexoid=186970index->hutz_idx_benefit=<span style="font-weight: bold; color: rgb(204, 0, 0);">2.02</span><br/> NOTICE: best_or_subclause_indexes():infos c=0: indexoid=186970 hutz_idx_benefit=<span style="font-weight:bold; color: rgb(204, 0, 0);">2.02</span><br /> NOTICE: best_or_subclause_indexes():infos c=1: indexoid=186970hutz_idx_benefit=<span style="font-weight: bold; color: rgb(204, 0, 0);">2.02</span><br /> NOTICE: best_or_subclause_indexes():infosc=2: indexoid=186970 hutz_idx_benefit=<span style="font-weight: bold; color: rgb(204, 0,0);">2.02</span><br /><br /><br /> From the output, it can be seen that when I try to read the value(s), the last valueis stored in all the positions of the List "infos" which is later assigned to "(IndexPath) pathnode->indexinfo" whichis a List of "IndexOptInfo" nodes, one per scan to be performed. Actually, it seems all the pointers in the List "indexinfo"or "infos" are pointing to the same object.<br /><br /> So, <br /> Ques 1) Is my assumption correct that IndexPath->indexinfoshould contain all distinct IndexOptInfo structs with one for each of the scans to be performed? Ifnot, then why do we have multiple pointers to the same object?<br /><br /> (Ques 2) How can this be fixed? Is this a bugor something else?<br /><br /> (Ques 3) Is this a problem in other areas as well, for example the following query doesn'tgive the expected values as well-<br /> select s_suppkey, c_custkey from supplier, customer where s_suppkey>125and s_suppkey<128 and c_custkey>125 and c_custkey<135 and c_custkey=s_suppkey;<br /><br /> I appreciateall the help of this group,<br /> Thanks,<br /><br /><br />On 5/25/05, Tom Lane <<a href="mailto:tgl@sss.pgh.pa.us">tgl@sss.pgh.pa.us</a>>wrote:<br />> Vikram Kalsi <<a href="mailto:vikramkalsi@gmail.com">vikramkalsi@gmail.com</a>>writes:<br />> > So, I suppose that during the queryplanning and optimization stage, <br />> > the value of the original variables in the plan are somehow copiedto<br />> > the plan which is finally returned inside pg_plan_query().<br />> <br />> Look in createplan.c--- there are a couple places in there you need to <br />> fix.<br />> <br />> regards, tom lane<br />> <br />
В списке pgsql-hackers по дате отправления: