Re: Performance for seq. scans - Mailing list pgsql-general

From Michael Blakeley
Subject Re: Performance for seq. scans
Date
Msg-id p04320401b5a4d46a79c4@blakeley.com
Whole thread Raw
In response to Performance for seq. scans  (Jules Bean <jules@jellybean.co.uk>)
List pgsql-general
>  From: Jules Bean <jules@jellybean.co.uk>
>  To: pgsql-general@postgresql.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

pgsql-general by date:

Previous
From: bmccoy@chapelperilous.net
Date:
Subject: Re: Performance for seq. scans
Next
From: Wilkinson Charlie E
Date:
Subject: RE: Access 97 Database and Postgres