Re: Is Patch Ok for deferred trigger disk queue?

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
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 359-1001
+ If your life is a hard drive, | 13 Roberts Road
+ Christ can be your backup. | Newtown Square, Pennsylvania 19073