Re: Performance for seq. scans
От | Michael Blakeley |
---|---|
Тема | Re: Performance for seq. scans |
Дата | |
Msg-id | p04320401b5a4d46a79c4@blakeley.com обсуждение исходный текст |
Ответ на | Performance for seq. scans (Jules Bean <jules@jellybean.co.uk>) |
Список | 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 по дате отправления: