On Thu, 27 May 2010 17:27:11 +0200, Paul McCullagh <[email protected]> wrote: > On May 27, 2010, at 4:51 PM, Stewart Smith wrote: > > On Thu, 27 May 2010 12:36:46 +0200, Paul McCullagh > > <[email protected] > > > wrote: > >> On May 26, 2010, at 5:26 AM, Stewart Smith wrote: > >>> class Tuple > >>> { > >>> Tuple(Tuple &t) > >>> { for(i= 0; i< t.nr_columns(); i++) { set_column(i, > >>> t.column(i)); } } > >>> } > >> > >> Currently, I can do this with one memcpy, in the cases when PBXT is > >> using a fixed length record structure. > >> > >> But, I guess this is a small price to pay for proper encapsulation. > > > > You could probably continue to do so, but the above would be the > > generic > > solution. > > Well, if I could, that would be great. I am thinking of the case where > you have a row consisting of 100 integers. > > That would mean the difference between 1 memcpy of 400 bytes or 100 4 > byte memcpy's. A big difference in this case.
Yep... optimised conversions would be a necessity. for updating a row that has 100 ints but you're only updating 1 int, you want to know that there's just 1. So optimised conversion routines could possibly get more complex due to efficiency gains elsewhere... > I would need a method that returns a pointer to the tuple buffer, and > the length of the buffer. The method could return NULL if the tuple > has no buffer, and then I could use the standard copy method. that could be one simple way to do it... > int Tupple::column_endian(int colnr) > > Based on the result, the engine would know whether to convert or not. (i'm going to try and think of a rather foolproof way to do endian safety here... i don't know the solution yet :) > >> Tuple record[2] > > > > Personally, I'd like this to end up just being a memory pool > > instead, as > > a lot of the time you don't actually need 2 records and it's just a > > waste of memory (especially for large tables). > > Yup, but a pool introduces another semaphore. And, there is already a > Handler pool. Just a pool in the Table, not global. Initial size would be 1, the 2nd only allocated when needed. > >> Although this may present a problem with regard to the scope of > >> validity of Tuples returned by the engine. > >> > >> The best for the moment would be that the Tuple is valid until the > >> next call to the engine on the Cursor that returned the Tuple. > > > > agreed. > > > > I wouldn't also mind a mechanism that could implement either: > > a) copying of the tuple > > b) retain/release > > Yes, this would be useful. And easy, as long as Tuples are not shared > between threads. Yep. It would be the upper layer who would have to get this right (e.g. by not sharing). > > so that if the upper layer did need it for longer it could ask the > > engine to keep it around and you'd either get a copy (by default) or > > if > > the engine is clever, just a reference to the same bit of memory. > > Yes, the engine may be able to do this without making a copy. That > would be an important optimization. basically pinning the appropriate pages in the buffer pool for some period of time. Not materialising blobs would be even better though :) -- Stewart Smith _______________________________________________ Mailing list: https://launchpad.net/~pbxt-discuss Post to : [email protected] Unsubscribe : https://launchpad.net/~pbxt-discuss More help : https://help.launchpad.net/ListHelp
