The following issue has been SUBMITTED. 
====================================================================== 
http://www.dbmail.org/mantis/view.php?id=690 
====================================================================== 
Reported By:                wak
Assigned To:                
====================================================================== 
Project:                    DBMail
Issue ID:                   690
Category:                   Database layer
Reproducibility:            N/A
Severity:                   feature
Priority:                   normal
Status:                     new
target:                      
====================================================================== 
Date Submitted:             31-Mar-08 22:25 CEST
Last Modified:              31-Mar-08 22:25 CEST
====================================================================== 
Summary:                    Possible performance impacts of dbmail_mimeparts on
pgsql
Description: 
Although the single instance mimepart approach of 2.3.2 is already quite
clever, when I start thinking of a *really* large mimeparts table - say:
millions of rows - I'm tempted to think this might not scale too well when
the hash and size columns are in the same table and get looked up every
time an insertion is done.
I'd suggest moving those two (not very space consuming) columns to a
distinct table.

In addition latest postgres versions offer some neat features for dealing
with huge amounts of data - this might be interesting for vacuuming,
archiving and backup and recovery as well:
- Tablespaces
- Inheritance for partitioning tables

An approach to deal with that would be defining a master table
dbmail_mimeparts
and inherited tables, e.g. dbmail_mimeparts_100000 (containing ids up to
100000), dbmail_mimeparts_200000 (containing ids up to 200000, and so
on...) - each with a distinct tablespace - possibly on a distinct storage
location. Assuming ids are ever increasing - this might even be an
approach to hsm where older records are located on slower disks.

However, db queries probably have to be adjusted to do this.

Any opinions on that?

kr, Wolfram
====================================================================== 

Issue History 
Date Modified   Username       Field                    Change               
====================================================================== 
31-Mar-08 22:25 wak            New Issue                                    
======================================================================

_______________________________________________
Dbmail-dev mailing list
[email protected]
http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Reply via email to