Thread: OidFunctionCall4

OidFunctionCall4

From
"Hicham G. Elmongui"
Date:
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




am i asking in the wrong place?

From
"Hicham G. Elmongui"
Date:
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
>


Re: OidFunctionCall4

From
Jonathan Gardner
Date:
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


Re: am i asking in the wrong place?

From
Gavin Sherry
Date:
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


pulling projection up in plans

From
"Hicham G. Elmongui"
Date:
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



Re: pulling projection up in plans

From
Tom Lane
Date:
"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


Re: pulling projection up in plans

From
Sailesh Krishnamurthy
Date:
>>>>> "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




Re: pulling projection up in plans

From
"Hicham G. Elmongui"
Date:
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
>
>