From: | Mark Stosberg <mark(at)summersault(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Can anyone make this code tighter? Too slow, Please help! |
Date: | 2007-02-09 21:04:31 |
Message-ID: | eqinlp$2vg7$1@news.hub.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
shane(dot)eckel(at)seattlesoftware(dot)com wrote:
> I have this function in my C#.NET app that goes out to find the
> business units for each event and returns a string (for my report).
> I'm finding that for larger reports it takes too long and times out.
>
> Does anyone know how I can speed this process up? Is this code very
> tight or could it be cleaner? thanks in advance for your help, this
> is a big issue used on several reports.
Perhaps try "EXPLAIN ANALYZE" on this query, given a valid event ID:
SELECT Distinct Companies.Name
FROM Companies INNER JOIN
ExpenseAllocations ON Companies.ID =
ExpenseAllocations.BusinessUnitID
WHERE (ExpenseAllocations.EventID =
@EventID)
ORDER BY Companies.Name DESC
#######
Do the columns used in the join and WHERE clause have indexes?
It's also possible the optimization needs to happen at a different level. Perhaps you are frequently
looking up the same results in a large report, or throughout the day.
If this part doesn't need to be up-to-second fresh, perhaps your application could
cache some of the results of this function, instead of repeatedly asking the database
to recompute it.
Mark
From | Date | Subject | |
---|---|---|---|
Next Message | Virag Saksena | 2007-02-10 00:00:18 | Is there an equivalent for Oracle's user_tables.num_rows |
Previous Message | Mark Stosberg | 2007-02-09 19:26:01 | cube operations slower than geo_distance() on production server |