2009/3/29 Tom Lane <t...@sss.pgh.pa.us>: > Hitoshi Harada <umi.tan...@gmail.com> writes: >> So I tried pass EState.es_tupleTables to tuplestore_begin_heap() to >> trace those TupleTableSlots. Note that if you pass NULL the behavior >> is as before so nothing's broken. Regression passes but I'm not quite >> sure EState.es_tupleTable is only place that holds TupleTableSlots >> passed to tuplestore... > > I've got zero confidence in that, and it seems pretty horrid from a > system structural point of view even if it worked: neither tuplestore.c > nor its direct callers have any business knowing where all the slots > are. What might be a bit saner is to remember the slot last passed to > tuplestore_gettupleslot for each read pointer. The implication would be > that we'd be assuming only one slot is used to fetch from any one read > pointer, but that is probably a reasonable restriction.
Hm, this choice is better than mine. But if we take this, I suppose we need to consider the way to break the restriction, for the case we will be forced to use many TupleTableSlots on one read pointer. Without that, I don't think it's a good idea to take this way. >> I know you propose should_copy boolean parameter would be added to >> tuplestore_gettupleslot(). > > I already did it, and concluded that not only were all the > tuplestore_gettupleslot calls in nodeWindowAgg broken, but so was > nodeCtescan. I'm open to reverting that patch if you have a better > solution though. For now, yours is the better than everything. As we're not staying here forever, let's choose copy way. Then I'll keep it in my mind and retry when I will improve the tuplestore performance, with the later window function's patch. Regards, -- Hitoshi Harada -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
