On 24/02/2012, at 2:22 AM, Simon Riggs wrote: >> Would appreciate some suggestions. > > You really need to explain why this matters...
I've just replied to Adrian with more details. I suppose you don't mind to take a look there so I won't copy-paste it :) > You mention a "typical Ruby on Rails app" and then discuss SQLite. > Well, typical web apps have more than 1 user, so fairly obviously > using SQLite isn't appropriate. This is rally irrelevant to this thread, but I believe you are not right here: http://www.sqlite.org/whentouse.html Websites SQLite usually will work great as the database engine for low to medium traffic websites (which is to say, 99.9% of all websites). > If SQLite isn't appropriate, why are > you testing with it? It is appropriate in the first place. But another reason to use SQLite for testing is that is fast and easy to maintain and setup. Since I need to use PG FTS (and that's the only reason), I have to use PG for testing too. And this is where this thread comes in. > Perhaps just run half the test, that would make it twice as quick and > still just as valid. > > If Postgres tests run in ~1 minute, what benefit have you gained from > saving 30 seconds? How often are you running tests? I think it is irrelevant to the this thread, but here's my math: I run full suite aprox every 5 mins. Which is ~ 100 times a day. Now, 30s*100 = 50mins vs 60s=100mins. This is another ~hour lost a day. On top of that I would run a single test file probably every couple of minutes or so. (So even if it is a couple of seconds slower, it all adds up a lot). This is just a common TDD style. Watch the https://www.destroyallsoftware.com/ for example to see what I mean. Don't get me wrong, I realise that PG and SQLite are totally different beasts. That's totally fine if PG can't beat SQLite on speed in **this particular case**. I just want to try to tune it to be as fast as it can (for **this particular case**, see my reply to Adrian). Cheers.
