Re: pulling projection up in plans

>>>>> "Tom" == Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:

Tom> "Hicham G. Elmongui" <elmongui(at)cs(dot)purdue(dot)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