Stuart wrote: > 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,
OK, we can do the trigger queue file for 7.5. The issue with sortmem is that its effect is to spill a sort out to file when it gets too large, the same for the trigger queue representation. We could rename it, but because it is _mostly_ used for sorts, we would probably keep the name the same and just mention the trigger queue effect in the docs. -- Bruce Momjian | http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup. | Newtown Square, Pennsylvania 19073 ---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match