> -----Original Message----- > From: Eran Tromer [mailto:[EMAIL PROTECTED] > Sent: Friday, April 29, 2005 2:42 PM > To: Tzahi Fadida > Cc: 'Linux-IL mailing list' > Subject: Re: cleaning memory. > > > On 29/04/05 15:36, Tzahi Fadida wrote: > > > Its just so I can see the bottlenecks and do the > experiments. On the > > large scale when the algorithm is run with other queries, the cache > > would be depleted anyway in favour of memory allocations > and compared > > to the size of the input it would be useless because of sequential > > scans. > > Running without cache will give you a lower bound on > performance, but no caching might be far slower than a little > caching, especially when it comes to indices and other metadata.
I agree, a little caching is good. btw, if you can cache metadata then you can cache the rest (at least from what I have been reading on the net). I need it to be bad so I can see the worse case. I have several algorithms for the same problem. theoretically I have the answer which is better on what conditions but I need to see it live so I am not making a mistake. And also learn, under what conditions in a real RDBMS recommend to the DB planner what algorithm to choose. The code is too complex to just say what is better, thus I need to experiment. > > > My last resort is to try to change the code of postgresql > to use the > > O_DIRECT but its never so simple as just changing an option when > > opening in one place. > > Note that O_DIRECT requires the buffers in read() and write() > to be aligned (to 512-byte boundaries, in kernel 2.6.x). > > Eran > > ================================================================= To unsubscribe, send mail to [EMAIL PROTECTED] with the word "unsubscribe" in the message body, e.g., run the command echo unsubscribe | mail [EMAIL PROTECTED]
