*** 68,73 **** --- 68,84 ---- *: nosync in case of SQLite means that SQLite is running with PRAGMA synchronous=OFF;. In case of MySQL it means that table type is MyISAM. *: sync in case of SQLite means that SQLite is running with PRAGMA synchronous=FULL;. In case of MySQL it means that table type is InnoDB. + *Comment*: You can turn off syncing (ie: nosync) in PostgreSQL by setting + 'fsync = false' in the postgresql.conf. This isn't a setting to be done + lightly, of course, but it might make for a more sensible comparison to + the other databases where you're turing sync on/off. + Additionally, it is reasonably common to run analyze frequently on tables + which are changing alot. PostgreSQL in general thinks about a table 'in + use' where rows are inserted, updated, and deleted during the lifetime of the + table while the general 'running size' and statistics are reasonably constant. + What that's about is that you might not run analyze before *every* query because + the overall statisitcs don't change that much, but you might run 'vacuum analyze' nightly to mark old rows as being replacable and update the statistics. For a test like this it does make sense to analyze after changes to the tables are made. If tables are reused (and rows are updated or deleted) then vacuum and/or vacuum full should be run. Lack of running analyze is probably the problem with Test 8, Postgres isn't using the index because it's going off the 'default' statistics, which indicates there's only 100 rows or some such and in a case like that a sequential scan is faster. An additional nicety might be to re-run the Postgres tests with 'explain analyze' for each query and provide that output as well to verify the query plan being used. + On to the tests now.
Small. Fast. Reliable.
Choose any three.
Choose any three.
|
|