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:

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 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

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: