Michael Monnerie wrote: > 64 queries per inserted e-mail is indeed very hard. I can imagine using > a reduced dbmail installation, without all the header cache information > like dbmail_tofield, *fromfield, *replytofield etc., as only a webapp > has access, which in turn is only there for a user to > 1) login (AUTH from outside dbmail) > 2) get a list of spams in box > 3) should there be a HAM he wants he clicks on it and says "deliver this > to me" > 4) a big "delete all" button
That smells like POP3 access. Like Marc's suggestion, perhaps we should offer a pop3-storage only mode (no headercaching, no envelope caching, etc). But that would not be possible on a per-user basis, only on a per-dbmail-instance basis. Not without changing the delivery chain very significantly. Sorry Marc. > so it's really a very specialised form of dbmail. Paul, would that > be "easily" possible, without having to patch around with every update > of dbmail? Yes. A pop3 delivery mode could easily be done with a couple of #ifdef's in the code. If that works out and people like/use it, making it a run-time config option becomes trivial. > With the reduced amount of tables, lots of queries, inserts and indizes > should be saved, improving throughput a lot. Sounds like fun. Yes. But 1k messages per second insertion is still quite a lot. It would still require something like 10 or 15 queries with around 7 or 8 insert/update queries for simple non-multipart messages. And 10-15k queries per second is still quite a lot in my experience. Hell, I've setup mysql-clusters which did 2000k queries per second sustained without breaking a sweat so it should be within reach for postgres. But ymmv. -- ________________________________________________________________ Paul Stevens paul at nfg.nl NET FACILITIES GROUP GPG/PGP: 1024D/11F8CD31 The Netherlands________________________________http://www.nfg.nl _______________________________________________ DBmail mailing list [email protected] https://mailman.fastxs.nl/mailman/listinfo/dbmail
