Hitoshi Harada writes:
> I don't think advising or documenting such restriction to the future
> programmer is a good idea from the point of encapsulation. I've come
> up with an idea, that the read pointers remember their last slot as
> you suggest and materialize it when another slot comes in
> t
2009/3/30 Tom Lane :
> Hitoshi Harada writes:
>> 2009/3/29 Tom Lane :
>>> ... 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
>>>
Hitoshi Harada writes:
> 2009/3/29 Tom Lane :
>> ... 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 probab
2009/3/29 Tom Lane :
> Hitoshi Harada 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
Hitoshi Harada 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 TupleTabl
2009/3/28 Tom Lane :
> Hitoshi Harada writes:
>> 2009/3/27 Hitoshi Harada :
>>> 2009/3/27 Tom Lane :
A brute-force solution is to change tuplestore_gettupleslot() so that it
always copies the tuple, but this would be wasted cycles for most uses
of tuplestores. I'm thinking of chang
Hitoshi Harada writes:
> 2009/3/27 Hitoshi Harada :
>> 2009/3/27 Tom Lane :
>>> A brute-force solution is to change tuplestore_gettupleslot() so that it
>>> always copies the tuple, but this would be wasted cycles for most uses
>>> of tuplestores. I'm thinking of changing tuplestore_gettupleslot'
2009/3/27 Hitoshi Harada :
> 2009/3/27 Tom Lane :
>> By chance I discovered that this query in the regression tests
>>
>> SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2;
>>
>> stops working if work_mem is small enough: it either dumps core or
>> delivers wrong answers de
2009/3/27 Tom Lane :
> By chance I discovered that this query in the regression tests
>
> SELECT ntile(NULL) OVER (ORDER BY ten, four), ten, four FROM tenk1 LIMIT 2;
>
> stops working if work_mem is small enough: it either dumps core or
> delivers wrong answers depending on platform.
>
> After some
Simon Riggs writes:
> Sounds very similar to the solution that you just removed from the hash
> join code for performance reasons. Flushing memory when we overflow
> sounds like an artifact from the time when tuplestore split from
> tuplesort. Can't we keep the appropriate rows in memory and scrol
On Thu, 2009-03-26 at 12:57 -0400, Tom Lane wrote:
> If work_mem is small enough, that means the tuplestore is
> forced into dump-to-disk mode, which means it releases all its
> in-memory tuples. And guess what: the ScanTupleSlot is pointing at
> one of those, it doesn't have its own copy of the
11 matches
Mail list logo
