I assume this will not be completed for 7.4. I will keep the emails for 7.5.
One idea I had was to use the existing sort_mem parameter to control when to force the deferred trigger queue to disk --- it doesn't have anything to do with sorting, but it does have the same purpose, to force thing to disk when we consume enough RAM.
---------------------------------------------------------------------------
Bruce Momjian wrote:
Stuart, were are on this patch? Seems we need GUC additions, though I can do that for you, and changes to write the head to disk. Was that completed?
---------------------------------------------------------------------------
Stuart wrote:
Tom Lane wrote:
Stephan Szabo <[EMAIL PROTECTED]> writes:
As a side question, it looks to me that the code stores the first trigger records in memory and then after some point starts storing all new records on disk. Is this correct? I'd wonder if that's really what you want in general, since I'd think that the earliest ones are the ones you're least likely to need until end of transaction (or set constraints in the fk case) whereas the most recent ones are possibly going to be immediate triggers which you're going to need as soon as the statement is done.
Good point. It would be better to push out stuff from the head of the queue, hoping that stuff near the end might never need to be written at all.
regards, tom lane
Hmmm.... I see your point. I will change the patch to write the head to disk and reenter when the development branch splits off. Also I've noticed that there is an fd.h which has file routines which I should be using rather than the stdio routines. I will also clean up those errors. Thank you, - Stuart
Sorry for the tardiness in replying, I've been away for the past week or so.
I didn't intend for 7.4 partly because I knew I'd be away & partly because I had seen there was a problem I hadn't realised with the previous patch and didn't want to submit something that may not be stable just before beta. Currently it compiles but there are some, er, issues - shouldn't take to long to fix but it might not be till wednesday as I've got a bit of a backlog to get through.
I could use sortmem, but if this is to be the case maybe there should be a change the call it something like max_local_mem with a way to register that you are using it. Maybe the memory allocs could automatically add to it and remove as memory is assigned. Alternativly just make a global to record the memory currently used by interested parties (currently the trigger & sortmem I'd guess). The only trouble with this that I can see is that the first one to claim the memory may claim it all, leaving nothing for the other. I'll carry on using the dedicated guc variable for the moment as I can't really see the correct way to solve this cleanly.
regards,
- Stuart
---------------------------(end of broadcast)--------------------------- TIP 7: don't forget to increase your free space map settings
