If you want to speed up the elapsed times, then the first thing would be to attempt to reduce the IO using some indexes, e.g. on test1(anumber), test2(anumber), test3((anumber%13)), test3((anumber%5)) and test4((anumber%27))

However if you wish to keep hammering the IO then the you would not use any indexes. However elapsed times for operations like:

CREATE TABLE test4 AS SELECT ... FROM test1 JOIN test2 ON test1.anumber=test2.anumber;

are going to increase non linearly with the size of the source table test1 (unless there are indexes on the anumber columns).

I think this particular test is designed as a testbed for measuring IO performance - as opposed to Postgresql performance.




Hi everyone,
I found that performance get worse as the size of a given table increases. I mean, for example Ive just run some scripts shown in


I understand that those scripts are designed to see the behavior of postgresql under different filesystems. However, since them generate
a lot of I/O activity, I think they can be used to adjust some configuration parameters. In that way, I increased the number of tuples inserted in the initial table to 2000000 and 3000000. What I saw is that the running time goes from 3 min., to 11 min. My question is, is it possible to use that test to tune some parameters?, if the answer is yes, what parameters should I change to get shorter running times?

---------------------------(end of broadcast)---------------------------
TIP 4: Don't 'kill -9' the postmaster

Reply via email to