Обсуждение: OidFunctionCall4
In "join_selectivity" function (plancat.c), a function call is made to "OidFunctionCall4" (fmgr.c), which in turn calls a function pointer. In need to know what is the actual function being called from OidFunctionCall4 if the selectivity of mergejoin is the one required from join_selectivity. Thanks
Hi everybody, I never meant my emails to be spam. That's why i am just asking whether my questions here are out of subject. Typically my questions are about postgresql source code, like the question below. Please advise me whether i should forward my questions to somewhere else. Thanks a lot, --h On Thu, 5 Aug 2004, Hicham G. Elmongui wrote: > In "join_selectivity" function (plancat.c), a function call is made to > "OidFunctionCall4" (fmgr.c), which in turn calls a function pointer. > > In need to know what is the actual function being called from > OidFunctionCall4 if the selectivity of mergejoin is the one required from > join_selectivity. > > Thanks > > > > ---------------------------(end of broadcast)--------------------------- > TIP 4: Don't 'kill -9' the postmaster >
On Thursday 05 August 2004 04:43 pm, Hicham G. Elmongui wrote: > In "join_selectivity" function (plancat.c), a function call is made to > "OidFunctionCall4" (fmgr.c), which in turn calls a function pointer. > > In need to know what is the actual function being called from > OidFunctionCall4 if the selectivity of mergejoin is the one required from > join_selectivity. > I'm no expert, but I can tell you from experience with the database that my first impression is that it is calling a function in the database (stored in pg_proc table or something like that). -- Jonathan Gardner jgardner@jonathangardner.net
On Mon, 9 Aug 2004, Hicham G. Elmongui wrote: > Hi everybody, > I never meant my emails to be spam. That's why i am just asking whether my > questions here are out of subject. Typically my questions are about > postgresql source code, like the question below. Please advise me whether > i should forward my questions to somewhere else. > Thanks a lot, > --h Most people are currently with beta and stuff. > > > On Thu, 5 Aug 2004, Hicham G. Elmongui wrote: > > > In "join_selectivity" function (plancat.c), a function call is made to > > "OidFunctionCall4" (fmgr.c), which in turn calls a function pointer. > > > > In need to know what is the actual function being called from > > OidFunctionCall4 if the selectivity of mergejoin is the one required from > > join_selectivity. Connect to the backend with a debugger such as gdb and step through the code and you will find it. Alternatively, have a better look at the code. The function called is that returned by get_oprjoin(). This looks up the operator (ie, '=', '<') in pg_operator and gets the function from there. For example, '=' is eqjoinsel() from memory. Gavin
Hi, is there a way to pull the projection operator to the top of the query plan? I wish there's a variable that can be set to do so. Thanks, --h
"Hicham G. Elmongui" <elmongui@cs.purdue.edu> writes:
> is there a way to pull the projection operator to the top of the query
> plan? I wish there's a variable that can be set to do so.
Could you be more specific about what you're hoping to accomplish?
regards, tom lane
>>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: Tom> "Hicham G. Elmongui" <elmongui@cs.purdue.edu> writes: >> is there a way to pull the projection operator to thetop of >> the query plan? I wish there's a variable that can be set to do >> so. Tom> Could you be more specific about what you're hoping to Tom> accomplish? This is just a suspicion, but I suspect that Hicham wants to avoid tuples being projected in Scan operators .. in a select (*) query projecting a tuple essentially causes a copy from the buffer pool to the backend process' heap space. I guess it would work just fine to have the tuple remain in the buffer and keep the buffer pinned. (In TelegraphCQ we actually do this .. we also don't really materialize join tuples - instead we have an "intermediate tuple format" which is a list of pointers to the various source tuples. This makes sense as we do shared query processing - ie. different queries with similar join predicates and different projection attributes use the same physical join tuples - projection is the final operation on the intermediate tuples when we return the tuples to clients. We did this really to facilitate sharing and don't really have any hard numbers on whether this would make sense in a general context with pgsql. Actually IIRC we did consider this - if this would make a diff to pgsql - and did some crude perf studies and found that it didn't really help if there was no sharing .. as is the case with pgsql). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh
To be more specific, i am trying to implement an operator, and i get the tuples being projected in ExecScan (called from ExecSeqScan). I just needed them unprojected. thanks, --h On Mon, 16 Aug 2004, Sailesh Krishnamurthy wrote: > >>>>> "Tom" == Tom Lane <tgl@sss.pgh.pa.us> writes: > > Tom> "Hicham G. Elmongui" <elmongui@cs.purdue.edu> writes: > >> is there a way to pull the projection operator to the top of > >> the query plan? I wish there's a variable that can be set to do > >> so. > > Tom> Could you be more specific about what you're hoping to > Tom> accomplish? > > This is just a suspicion, but I suspect that Hicham wants to avoid > tuples being projected in Scan operators .. in a select (*) query > projecting a tuple essentially causes a copy from the buffer pool to > the backend process' heap space. I guess it would work just fine to > have the tuple remain in the buffer and keep the buffer pinned. > > (In TelegraphCQ we actually do this .. we also don't really > materialize join tuples - instead we have an "intermediate tuple > format" which is a list of pointers to the various source tuples. This > makes sense as we do shared query processing - ie. different queries > with similar join predicates and different projection attributes use > the same physical join tuples - projection is the final operation on > the intermediate tuples when we return the tuples to clients. We did > this really to facilitate sharing and don't really have any hard > numbers on whether this would make sense in a general context with > pgsql. Actually IIRC we did consider this - if this would make a diff > to pgsql - and did some crude perf studies and found that it didn't > really help if there was no sharing .. as is the case with pgsql). > > -- > Pip-pip > Sailesh > http://www.cs.berkeley.edu/~sailesh > >