Re: Optimise PostgreSQL for fast testing
От | Alban Hertroys |
---|---|
Тема | Re: Optimise PostgreSQL for fast testing |
Дата | |
Msg-id | 815026BA-A4D6-4F8A-92CA-548CE25E9CFE@gmail.com обсуждение исходный текст |
Ответ на | Re: Optimise PostgreSQL for fast testing (Dmytrii Nagirniak <dnagir@gmail.com>) |
Список | pgsql-general |
On 24 Feb 2012, at 1:00, Dmytrii Nagirniak wrote: >> 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 queriesuse 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). With that few records you probably don't benefit from any indexes on those tables; they take time to update, but the queriesare not going to make use of them because sequential scans are likely to be faster. You still need some for some constraints, of course - the majority of those will probably be primary keys. Since you truncate those tables anyway, autovacuum probably gets in your way more than it helps and it's unlikely it cankeep up with the rate of changes. Turning it off and vacuuming between tests probably improves things. This also seems a rather pessimistic workload for any caches you have. I think you get very few requests for the same data?You said you tried a RAM disk for storage and it didn't improve much, which supports that theory. Disk cache probablydoesn't help you very much then, you could try reducing that and increase the memory assigned to PG, although I'mleft wondering what it could use the extra memory for with this workload... And as others said, use EXPLAIN ANALYSE on the slower queries to see why they are slow. With that knowledge you may be ableto speed them up (often significantly). And look into parallelising that workload. PG was designed for parallel workloads. Using a single process you're still payingfor that and not benefitting. Alban Hertroys -- Screwing up is an excellent way to attach something to the ceiling.
В списке pgsql-general по дате отправления: