Aaron Stone <[EMAIL PROTECTED]> said:
> Sean Chittenden <[EMAIL PROTECTED]> said:
>
>>> So, a detail that I hope a PostgreSQL person can answer definitively:
>>> will wrapping the delivery into a transaction prevent rows that are
>>> eventually deleted from even hitting the database?
>>
>> Sadly, no: but it will help throughput and performance to wrap things
>> in a transaction. You're better off investigating the possibility of
>> having a copy-on-write methodology wherein a message is added to the
>> database, then user accounts point to a given message id. When the
>> message is updated, it copies itself to a new message/message id and
>> the change cascades downwards. This would save space and IO. -sc
>
> The message blocks themselves aren't (well, they shouldn't...) be copied,
> just the message (and physmessage?) entries. It's been a while since I was
> deep in that code, though, so I don't remember if we really did finish
> getting rid of the actual messageblk copy.
Wait, I didn't finish that thought :-P
So the necessary rearchitecture would involve delivering the messageblks
first into a memory table, and only copying them into an on-disk table if
there are local recipients. I believe that this method was used in an
early pre-1.0 version of DBMail, and replaced with a locally in-memory
system, which I replaced with the internal user system. My way makes it
possible to store arbitrarily large messages without requiring them to be
in memory all at once, which I think is a pretty important part of the
design. **
Ok, looking at the TODO (these are in the 2.1 section):
- Rather than always deleting messages after delivery, make
it part of dbmail-util to clean out the special delivery user.
- Import and export users and mailboxes to mbox format.
- Combine the above two to allow for logging of all incoming messages
(e.g. USA banks are required to archive all email by law).
Ok, I feel much better now that I've already thought of most of this ;-)
So much for a quick-fix for PostgreSQL users during 2.0... keep those
daily vacuums running for now.
Aaron
** Sidenote: I thought that the retrieval functions did this same thing by
retrieving only one row at a time from the database, sending it over the
wire, and repeat until all messageblks are sent. But apparently not; it's
already been filed as a bug.
