In the 1.2 series, we tried to keep memory usage lower by only pulling in 512K of each message into memory at a time, then dumping to the database, and pulling in the next 512K. This was possible to do at the time because the hokey mime/header parser only wanted to see that all of the headers fit into the first 512K block.
GMime has some stream-oriented functionality, but we're primarily using it in an all-in-memory mode, on the whole message. Aaron On Thu, Dec 21, 2006, Matthew O'Connor <[email protected]> said: > I always thought that messages were split into blocks for MySQL, anyway, > bytea fields in PGSQL can support upto 1GB of data. > > Paul J Stevens wrote: >> That's just for historical reasons. >> >> READ_BLOCK_SIZE is defined in db.h as 512KB, but you can set it to 512MB >> or even bigger. Mysql supports 4GB for the type in question (longblob), >> but check the docs if you're using postgresql. >> >> >> tom wrote: >>> What motivated dbmail to split the messages into message_blks? >>> Is there some insane impracticality to storing a 1MB body as a single >>> text field? >>> _______________________________________________ >>> DBmail mailing list >>> [email protected] >>> https://mailman.fastxs.nl/mailman/listinfo/dbmail >>> >> >> > _______________________________________________ > DBmail mailing list > [email protected] > https://mailman.fastxs.nl/mailman/listinfo/dbmail > -- _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
