In article <44F44F44.1010104@xxxxxxxxxxxxxxxxx>, Joshua D. Drake <jd@xxxxxxxxxxxxxxxxx> wrote: % Patrick TJ McPhee wrote: [...] [the query is "select 1"] % > But if I turn on duration logging, I get timings like % > LOG: duration: 91.480 ms [...] % Vacuum? Analyze? I had autovacuum on initially, but turned it off. The slowness was in evidence from the point the data was loaded, when presumably vacuum would be superfluous. The data is analyzed. Right now, I'm not so worried about my real data as "select 1" being two orders of magnitude slower than I'd expect it to be. Steve Poe asked if I've modified postgresql.conf, and if the database and logs are on separate volumes. The .conf file has the memory parameters (shared buffers, work mem, effective cache size, etc) bumped up quite a bit. We have the block size set to 16k and the statistics target has been increased from the default. I had some of the planner costs adjusted as well, but they don't seem to be material to the problem. It's basically a copy of the .conf file that's working well in production on similar hardware under NetBSD. The logs and data are all one file system, which seems to be on a logical volume with a single disk sitting under it. Florian Pflug reports that he had a similar problem due to a slow RAID controller driver, to which I have no comment. Thanks for your comments. -- Patrick TJ McPhee North York Canada ptjm@xxxxxxxxxxxx
