This might not solve all your issues, but I'd suggest changing the types of the serial number columns so that your indexes actually come into play. You might want to ask postgres to explain its plan for the query above to confirm that this is a problem for you ("EXPLAIN SELECT sdt.name..."), but I'll bet it is.
Se also the thread http://thread.gmane.org/gmane.comp.otrs.devel/530, where Robert Mathews outlines a way to change the type of these columns in-place. (He does this to harmonize the columns to bigint; I'd suggest going from bigint to conventional int.)
Thanks for the info Arne. Here's pg's explain output: Sort (cost=7132.87..7132.87 rows=1 width=3062) Sort Key: sa.id -> Nested Loop (cost=1716.31..7132.86 rows=1 width=3062) Join Filter: ("outer".ticket_id = "inner".id) -> Seq Scan on article sa (cost=0.00..5379.65 rows=2 width=1485) Filter: (id = 44681) -> Materialize (cost=1716.31..1724.51 rows=820 width=1581) -> Hash Join (cost=1.19..1716.31 rows=820 width=1581) Hash Cond: ("outer".user_id = "inner".id) -> Seq Scan on ticket st (cost=0.00..1652.28 rows=10928 width=1513) -> Hash (cost=1.15..1.15 rows=15 width=72) -> Seq Scan on system_user su (cost=0.00..1.15 rows=15 width=72) It does appear to be using the index "article_pkey" (sa.id) unless I'm reading the above incorrectly... I'll give the other link (bigint-int) a try and see, but I doubt this will have a major impact on the problem. Henry -------------------------------------------------------- This message was sent using MetroWEB's AirMail service. http://www.metroweb.co.za/ - full access for only R73. Free Web Accelerator, WebMail, Calendar, Anti-Virus, Anti-Spam, 10 emails, 100MB personal webspace, and more! Phone Now! 086 11 11 440