Hitoshi Harada umi.tan...@gmail.com 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
2009/3/30 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2009/3/29 Tom Lane t...@sss.pgh.pa.us:
... 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
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
Hitoshi Harada umi.tan...@gmail.com writes:
2009/3/29 Tom Lane t...@sss.pgh.pa.us:
... 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
2009/3/28 Tom Lane t...@sss.pgh.pa.us:
Hitoshi Harada umi.tan...@gmail.com writes:
2009/3/27 Hitoshi Harada umi.tan...@gmail.com:
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
A brute-force solution is to change tuplestore_gettupleslot() so that it
always copies the tuple, but this would be wasted
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
2009/3/27 Hitoshi Harada umi.tan...@gmail.com:
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
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
Hitoshi Harada umi.tan...@gmail.com writes:
2009/3/27 Hitoshi Harada umi.tan...@gmail.com:
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
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.
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
Simon Riggs si...@2ndquadrant.com 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
2009/3/27 Tom Lane t...@sss.pgh.pa.us:
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.
11 matches
Mail list logo
