<div style="background-color:"><p>I have a query that runs about 30-50 seconds. The query is a join between 2 tables
(customerand address), each table with about 400,000 rows. My customer table has fields like first_name and last_name
wherethe address table has city, state, etc. I'm using "like" in most of the query columns, which all have indexes.
Theactual query is:<br /><br />SELECT p.party_id, p.first_name, p.last_name, pli.address1, pli.city, pli.state FROM
customeras 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>When the query runs, the hard drive lights up for the duration. (I'm confused by
thisas '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,
sharedbuffers, and OS shmmax with little change in the query performance.<p>Q: Would this query benefit from using a
viewbetween these two tables?<p>Q: Any idea why the reported swap usage is so low, yet the query slams the drive? Is
postgresnot caching this data? If I run the query with the same arguments, it comes right back the second time. If I
changethe args and re-run, it goes back to the hard drive and takes 30-50 seconds. <p>Suggestions very
welcome,<p>Tom<p> </div><brclear="all" /><hr /><a href="http://g.msn.com/8HMAENUS/2728??PS=47575" target="_top">Who's
thaton the Red Carpet? Play & win glamorous prizes.</a>
