Hi Aaron,
> >> At the moment queries seem to be spread over dbmail. Is it hard to use a
> >> more layered approach with a defined storage layer?
> > The retrieval api must indeed be totally opaque, while still allowing full
> > control over retrieval-conditions. Returning cursors where possible,
Hi Paul,
> >At the moment queries seem to be spread over dbmail. Is it hard to use a
> >more layered approach with a defined storage layer? A interface could be
> >something like 'sl_retrieve_message(user, mailbox, condition)' where
> >condition could be all/header=xyz/...
>
> Sounds a lot like w
Alternatively, is there something really simple like a flag we can pass
with the query that tells PostgreSQL not to cache the entire result
set?
I haven't read the whole thread, but dbmail would be a fantastic
example of an application that should use a CURSOR. Not only are they
more memory
Paul J Stevens <[EMAIL PROTECTED]> said:
> Thomas Mueller wrote:
>
>> At the moment queries seem to be spread over dbmail. Is it hard to use a
>> more layered approach with a defined storage layer? A interface could be
>> something like 'sl_retrieve_message(user, mailbox, condition)' where
>> con
Thomas Mueller wrote:
At the moment queries seem to be spread over dbmail. Is it hard to use a
more layered approach with a defined storage layer? A interface could be
something like 'sl_retrieve_message(user, mailbox, condition)' where
condition could be all/header=xyz/...
Sounds a lot like
Hi,
sometimes my server uses for some minutes much more memory than it
should - and I guess it's dbmail.
I hope I'll find some time soon to use a profiler, but meanwhile I guess
the following happens: someone marks a mailbox for offline use and
dbmail-imapd does the following:
- fetch all mails f
