Abhijit Menon-Sen wrote:
At 2013-11-24 12:51:55 +0100, a...@gulbrandsen.priv.no wrote:
What do you think about my suggested change? (To recap, it adds a
possibility to read bodyparts from files and an aox command to move
all binary bodyparts over size x out to files.)
I think that's OK.
If
On Sun, Nov 24, 2013 at 11:34:01AM +0100, Axel Rau wrote:
Sure. I would never destroy a clean architecture instead of tuning a DB.
Well, Stephen has a point about the dump/restore/migration problem.
What do you think about my suggested change? (To recap, it adds a
possibility to read bodyparts
On 22/11/2013 09:15, Usman Malik wrote:
Not knowing much about mail protocols, the way I think about solving
attachments (and decoupling it from db) is as following. The approach
is mostly geared towards web-mail services and is most likely outside
the scope of a typical email server. Today's
On Thu, Nov 21, 2013 at 05:15:16PM +0100, Stephen R. van den Berg wrote:
Why should we be modifying the database?
I was thinking of the fsck operation to fix the mime headers and
messages.rfc822.size.
What I would like to propose and implement is non-destructive on the db,
i.e. the db should
Lee Garrett answers me:
What? Doesn't the autovacuumer start to free up space after a few
seconds and then the space will gradually become available?
No, that's not how autovacuum works. See
http://www.postgresql.org/docs/9.3/static/sql-vacuum.html.
Regarding plain vacuum: However, extra
Arnt Gulbrandsen wrote:
Wow. I disagree with almost everything you write.
Well, maybe that indicates we start with wildly differing assumptions.
On Wed, Nov 20, 2013 at 12:54:22PM +0100, Stephen R. van den Berg wrote:
Externalising the attachments allows for some extra flexibility:
- When
Arnt Gulbrandsen wrote:
On 11/14/2012 03:32 PM, Martin Rode wrote:
The point is, you can do incremental backups easily if you store
attachments in files. If you store them inside the database a full dump
gets huge and can take a lot of time.
Yes. An artifact of pg_dump (and dumpall). IMO PITR
Let's see.. several points.
1. While it's correct that RDBMSes aren't designed for storing large
blobs, they also aren't designed for NOT doing that. RDBMSes are
designed for storing predominantly small items linked according to a
schema. The key word there is predominantly. The occasional
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes:
7. Archiveopteryx development is now just what I want, and I'm mostly
happy. I think there are more mail messages stored in archiveopteryx
databases than humans on earth, so imminent death is not to be
expected. But also not great new
On 11/19/2012 12:01 PM, Tom Ivar Helbekkmo wrote:
Arnt Gulbrandsen a...@gulbrandsen.priv.no writes:
7. Archiveopteryx development is now just what I want, and I'm mostly
happy. I think there are more mail messages stored in archiveopteryx
databases than humans on earth, so imminent death is
Here's a weird idea but might work:
Modify your webmail program to try to fetch the attachment from the filesystem.
If this fails, fall back to pulling it straight from the database. You then
have a task (a trigger? a cron job?) that exports the big attachments from the
database to the
[This was sent off-list and forwarded to me to resend to the list. It
wasn't signed, but I assume from context that it's from Usman.]
Thank you for your feedback.
Arnt, Mark, Martin,
Backup is not my concern for not storing attachments in db. IMHO dbs
are not meant for storing most
Abhijit Menon-Sen a...@toroid.org writes:
#1 This is not ideal not related to aox, but a postgresql question:
is it possible to specificity a different directory for attachments
table? I am thinking about a remote mounted directly, but like I said,
not ideal - just curious.
Sure -
I can't comment about scaling to this size, but it should be possible. However,
I do wonder why you want to move attachments out of the database? You do
realize that the attachments are also deduplicated, right? Send a 1MB
attachment to a million users on your service and it will only be stored
There aren't any limitations that matter; you'll probably want to listen
for a couple of database signals. mailboxes_updated is a crock and will
sooner or later make trouble.
I think your design makes a very great deal of sense. In fact it's about
the same as what I now wish Abhijit and I had
On 14.11.2012 15:09, Arnt Gulbrandsen wrote:
Oh. I missed that bit.
Taking attachments out of the DB makes sense in two cases:
- the db schema is poor (not the case for aox).
- the db client library sucks.
- db backups are getting too big
Arnt
Martin
On 11/14/2012 03:16 PM, Martin Rode wrote:
- db backups are getting too big
They don't grow any smaller by moving half the database from
/usr/local/postgres to /usr/local/homebrew.
You can shrink the backups by deleting attachments (conditionally,
blah), or by not backing up the entire db.
On 14.11.2012 15:33, Arnt Gulbrandsen wrote:
On 11/14/2012 03:16 PM, Martin Rode wrote:
- db backups are getting too big
They don't grow any smaller by moving half the database from
/usr/local/postgres to /usr/local/homebrew.
The point is, you can do incremental backups easily if you store
On 11/14/2012 03:32 PM, Martin Rode wrote:
The point is, you can do incremental backups easily if you store
attachments in files. If you store them inside the database a full dump
gets huge and can take a lot of time.
Yes. An artifact of pg_dump (and dumpall). IMO PITR backups are a better
Sorry, Arnt, that should go to the list:
Am 14.11.2012 um 15:51 schrieb Arnt Gulbrandsen:
On 11/14/2012 03:32 PM, Martin Rode wrote:
The point is, you can do incremental backups easily if you store
attachments in files. If you store them inside the database a full dump
gets huge and can take
I am trying to figure out whether or not archiveopteryx is the right
solution for a large scale (say millions of users) mail. There is not
much on this topic (or user experiences) on google so I am reaching
out to you on this list.
This would be mostly a webmail system, so I figured using DB
21 matches
Mail list logo
