On Tue, Feb 07, 2006 at 10:08:23AM +0100, Nemanja Corlija wrote: > On 2/7/06, Jim C. Nasby <[EMAIL PROTECTED]> wrote: > > On Tue, Feb 07, 2006 at 07:31:50AM +0100, Nemanja Corlija wrote: > > > > Well, that certainly won't help things... at a minimum, on your machine, > > > > you should change the following: > > > > shared_buffers=10000 > > > > effective_cache_size=100000 > > > > > > > > The following should also help: > > > > work_mem=10000 > > > > vacuum_cost_delay=50 > > > > autovacuum=on > > > > autovacuum_vacuum_scale_factor=0.2 > > > Sure, I could do that. But then I'd also need to tune all other > > > databases to make things fair and that's not really what I intended to > > > do here. I want to keep things as "out of the box" as possible. > > > > Then you should just drop PostgreSQL from the tests, because they're not > > doing anyone any good. It's pretty well known that the default > > postgresql.conf is meant to allow for bringing the database up on a > > machine with very minimal hardware. It's the equivalent to using MySQL's > > minimum configuration file. > > OK, I've changed above settings but now I get even worse performance. > 265.223 seconds. > File I've edited is C:\Program Files\PostgreSQL\8.1\data\postgresql.conf > AFAICT that's the one. Then I've restarted postgres. I guess that > should load new settings? > Then I ran VACUUM ANALYZE t2; > > Hmmm, now I ran that same script from pgAdmin and it completed in 5 seconds. > I guess its reasonable to assume that psql is actually the bottleneck > here. I tried redirecting to file but that was a minute ago and it's > still running. Any ideas?
Hrm, that's rather odd. What does top show when it's running through psql? Are the test scripts available for download? I'll try this on my machine as well... -- Jim C. Nasby, Sr. Engineering Consultant [EMAIL PROTECTED] Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461
