From: | Michael Blakeley <mike(at)blakeley(dot)com> |
---|---|
To: | Jules Bean <jules(at)jellybean(dot)co(dot)uk>, pgsql-general(at)hub(dot)org |
Subject: | Re: Performance for seq. scans |
Date: | 2000-07-26 17:50:03 |
Message-ID: | p04320401b5a4d46a79c4@blakeley.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
> From: Jules Bean <jules(at)jellybean(dot)co(dot)uk>
> To: pgsql-general(at)postgresql(dot)org
> Subject: Performance for seq. scans
>
> I've had a look over the docs and the FAQ and I can't see anything
> answering this, so here goes:
>
> I'm in the (slightly unusual, in a relational world) situation that
> the dominant query on my database is a wildcard search, so that no
> indexes can be used. (E.g. select * from table_a where foo like
> '%bar%').
>
> Interestingly, using 'vmstat' shows that the CPU is maxxed out at 50%
> (this being a dual CPU machine), while the disk access is a mere
> 4M/sec --- bonnie claims this machine is capable of around 25M/sec to
> this particular disk. So it would seem that the bottleneck is the
> CPU. [I understand why both CPUs aren't used]
I'd make sure that you're using the latest compilers to build
postgres, and maxing-out the optimization. If you're binaries are
unoptimized, that ought to be good for 15% (for your app, possibly
more).
Also, you haven't said what postmaster options you're using - I've
seen big changes by tweaking sort memory, buffer pools, etc. Details
of the parameters are in the man pages and docs.
-- Mike
From | Date | Subject | |
---|---|---|---|
Next Message | Wilkinson Charlie E | 2000-07-26 17:59:33 | RE: Access 97 Database and Postgres |
Previous Message | bmccoy | 2000-07-26 16:59:43 | Re: Performance for seq. scans |