Re: Optimise PostgreSQL for fast testing

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.