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



Thu, 5 Aug 2004 18:43:04 -0500
"Hicham G. Elmongui" <elmongui@cs.purdue.edu>
OidFunctionCall4
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
>

Mon, 9 Aug 2004 15:23:37 -0500 (EST)
"Hicham G. Elmongui" <elmongui@cs.purdue.edu>
am i asking in the wrong place?
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

Mon, 9 Aug 2004 16:22:54 -0700
Jonathan Gardner <jgardner@jonathangardner.net>
Re: OidFunctionCall4
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

Tue, 10 Aug 2004 09:44:09 +1000 (EST)
Gavin Sherry <swm@linuxworld.com.au>
Re: am i asking in the wrong place?
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


Mon, 16 Aug 2004 17:37:31 -0500 (EST)
"Hicham G. Elmongui" <elmongui@cs.purdue.edu>
pulling projection up in plans
"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

Mon, 16 Aug 2004 19:19:21 -0400
Tom Lane <tgl@sss.pgh.pa.us>
Re: pulling projection up in plans 
>>>>> "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



Mon, 16 Aug 2004 17:28:07 -0700
Sailesh Krishnamurthy <sailesh@cs.berkeley.edu>
Re: pulling projection up in plans
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
>
>

Tue, 17 Aug 2004 03:36:27 -0500 (EST)
"Hicham G. Elmongui" <elmongui@cs.purdue.edu>
Re: pulling projection up in plans