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