Re: tuplestore API problem

2009/3/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Hitoshi Harada <umi(dot)tanuki(at)gmail(dot)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