> 1. Postgres appears to have a fairly high row overhead (40 bytes
> or so according to the FAQ), which grieves me slightly, as that's
> actually larger than the size of the data in my tuples. It would
> seem that in my case some of the items in that header (the OID and
> the NULL bitfield) are not used; would it be possible to avoid
> allocating these in this relations that don't use them?
CREATE TABLE WITHOUT OIDS ...
> As well, index builds seem to take about 20% longer (using -F), and they
> seem to be about 10% larger as well.
> > Does anybody have any suggestions as to how I can improve performance
> here, and reduce disk space requirements? If not, I'll probably have
> to suggest to the client that he move to MySQL for this particular
> application, unless he needs any of the features that Postgres provides
> and MySQL doesn't.
This conclusion seems to me to be remarkably shortsighted. Does the initial
data load into the database occur just once or quite often? If just once,
then the initial loading time doesn't matter.
It's a bit hard to say "just turn off all the things that ensure your data
integrity so it runs a bit faster", if you actually need data integrity.
Anyway, from what I understand an OLTP application is all about selects and
memoising certain aggregate results. Since Postgres has far more advanced
indexing and trigger support than MySQL, surely you need to take this kind
of difference into account??? The fact that you can load stuff quicker in
MySQL and it takes up less disk space seems totally irrelevant.
Just wait until your MySQL server crashes and your client finds that half
his data is corrupted...
Chris