In article <44F44F44.1010104@commandprompt.com>,
Joshua D. Drake <jd@commandprompt.com> 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@interlog.com
