Re: Optimise PostgreSQL for fast testing
| От | Dmytrii Nagirniak |
|---|---|
| Тема | Re: Optimise PostgreSQL for fast testing |
| Дата | |
| Msg-id | 80D83060-25F0-46FB-856F-50503B174C25@gmail.com обсуждение исходный текст |
| Ответ на | Re: Optimise PostgreSQL for fast testing (Adrian Klaver <adrian.klaver@gmail.com>) |
| Ответы |
Re: Optimise PostgreSQL for fast testing
Re: Optimise PostgreSQL for fast testing |
| Список | pgsql-general |
On 24/02/2012, at 2:06 AM, Adrian Klaver wrote:
Would appreciate some suggestions.
Not enough information to make suggestions.
Jack Christensen pretty nailed it very well. But I'll answer the particulars here too:
Why are you switching databases?
Need FTS from PG. No other reasons yet.
What are the specs?
A typical DB spec (test) does the following:
1. Creates a number of records (commonly about 5-ish, but may vary from 1 to ~40 across all tables).
2. Executes some queries against the dataset (**MOST** of them are pretty simple, with only 1-2 joins; only some queries use 5-ish joins, sorting, distinct etc).
3. May update couple of records too (we are talking about a couple only, so it in the range of 1-5, very rarely ~20-30).
4. At the end a spec truncates all the tables (uses truncate, not delete).
This repeats on every spec/test (hundreds of those).
What is the application?
As I said, it is a typical Rails web application.
But for the purpose of this thread it is irrelevant since we're basically talking about single user, development/test environment where the only user of the app is the "spec/test" and no concurrency.
What is the use case?
Single user?
Networked, multiple user?
See above.
No. As I said before the database is used ONLY for running tests and can be recreated at any time.Do you see the application/database growing?
Generally it will never have any data in it (except when specs are running).
Cheers.
В списке pgsql-general по дате отправления: