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 <[EMAIL PROTECTED]> writes: > > Tom> "Hicham G. Elmongui" <[EMAIL PROTECTED]> 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 > > ---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
