Marc Dirix wrote: >> >> Also, the schema in the dbmail sources makes heavy use of the INT8 data >> type. PG handles those much better on an -m64 compile than on a -m32 >> compile. The speed increase I got when I converted my personal mail >> store to use INT4 everywhere INT8 is currently specified -- except for >> the dbmail_users table; my curmail_size is greater than 2 Gigs -- was >> significant. And I cut my disk space usage by about half. >> > > I second that!
I'd like to see a proposal on how to change the schema to do that. So what fields can safely be changed from int8 to int4, what fields need extra precautions or even code changes, and what fields do warrant int8. I'm none to happy with the current prevalence of guint64 either, if only because of the massive amounts of warnings I get while compiling on amd64. If we can cut storage space by half for some people, that alone would be more than enough reason to work on this. -- ________________________________________________________________ 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
