From: | "Nick Fankhauser" <nickf(at)ontko(dot)com> |
---|---|
To: | "Frank Bax" <fbax(at)sympatico(dot)ca>, <pgsql-sql(at)postgresql(dot)org>, "Guru\(External\)" <guru(at)indvalley(dot)com> |
Subject: | Re: Resources |
Date: | 2002-01-11 16:56:08 |
Message-ID: | NEBBLAAHGLEEPCGOBHDGEEOKECAA.nickf@ontko.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-sql |
> Sorry, I made too general a statement. Index will help when the expession
...and I didn't notice that Gurudutt's LIKE wasn't anchored to the front.
oops- mea culpa.
Taking a second look then, the LIKE is probably very costly.
Take a look at the section in the Docs on making explicit joins. If the date
check significantly constrains the results, index it & then make sure that
constraint gets evaluated first, then the sequential scan on the address has
less to scan. This might help a lot.
The doc page for explicit joins:
http://www.postgresql.org/idocs/index.php?explicit-joins.html
You mention that it may be too late to change the tables, but I guess that's
where I'd look next- I once had a similar situation when I worked for an
electric utility & we ended up parsing the address lines to find road names
& numbers and then loading them into special indexed fields just used for
sorting. If you control the input app, maybe you could even have the user
enter the fields you want to query on separately.
-Nick
From | Date | Subject | |
---|---|---|---|
Next Message | Peter T. Brown | 2002-01-11 17:17:48 | Re: Temporary tables |
Previous Message | Frank Bax | 2002-01-11 16:27:58 | Re: Resources |