<html><div style='background-color:'><P>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:<BR><BR>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<BR></P>
<P>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.</P>
<P>Q: Would this query benefit from using a view between these two tables?</P>
<P>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. </P>
<P>Suggestions very welcome,</P>
<P>Tom</P>
<P> </P></div><br clear=all><hr> <a href="http://g.msn.com/8HMAENUS/2728??PS=47575" target="_top">Who's that on the Red Carpet? Play & win glamorous prizes.</a> </html>