I have a query that runs about 30-50 seconds.  The query is a join between 2 tables (customer and address), each table with about 400,000 rows.  My customer table has fields like first_name and last_name where the address table has city, state, etc.  I'm using "like" in most of the query columns, which all have indexes.  The actual query is:

SELECT p.party_id, p.first_name, p.last_name, pli.address1, pli.city, pli.state FROM customer as p JOIN address as pli ON ( p.party_id = pli.party_id ) WHERE ( p.void_flag IS NULL OR p.void_flag = false )  AND  (first_name like 'B%') AND (last_name like 'S%') AND (pli.state like 'M%') AND (pli.city like 'AL%') ORDER BY last_name, first_name LIMIT 51

When the query runs, the hard drive lights up for the duration.  (I'm confused by this as 'top' reports only 24k of swap in use).  My SUSE 9 test machine has 512 Meg of RAM with 300 Meg used by a Java app.  Postmaster reports 56 Meg under "top" and has a 52 Meg segment under "ipcs".  I've played with the cache size, shared buffers, and OS shmmax with little change in the query performance.

Q: Would this query benefit from using a view between these two tables?

Q: Any idea why the reported swap usage is so low, yet the query slams the drive?  Is postgres not caching this data?  If I run the query with the same arguments, it comes right back the second time.  If I change the args and re-run, it goes back to the hard drive and takes 30-50 seconds. 

Suggestions very welcome,

Tom