Re: Is Patch Ok for deferred trigger disk queue?

Bruce Momjian wrote:
> 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 <sszabo(at)megazone23(dot)bigpanda(dot)com> 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