Re: tuplestore API problem
От | Simon Riggs |
---|---|
Тема | Re: tuplestore API problem |
Дата | |
Msg-id | 1238090766.16568.524.camel@ebony.2ndQuadrant обсуждение исходный текст |
Ответ на | tuplestore API problem (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: tuplestore API problem
|
Список | pgsql-hackers |
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 tuple. So we wind > up trying to read from a trashed bit of memory. > > 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's API > to add a bool parameter specifying whether the caller wants to force > a copy. > > Comments, better ideas? 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 scroll through them? -- Simon Riggs www.2ndQuadrant.comPostgreSQL Training, Services and Support
В списке pgsql-hackers по дате отправления: