From: | "Joel Fradkin" <jfradkin(at)wazagua(dot)com> |
---|---|
To: | "'Dave Page'" <dpage(at)vale-housing(dot)co(dot)uk>, "'PostgreSQL Perform'" <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: speed of querry? |
Date: | 2005-04-18 13:31:57 |
Message-ID: | 000801c5441a$fe9010e0$797ba8c0@jfradkin |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
pgAdmin III uses libpq, not the ODBC driver.
Sorry I am not too aware of all the semantics.
I guess the question is if it is normal to take 2 mins to get 160K of
records, or is there something else I can do (I plan on limiting the query
screens using limit and offset; I realize this will only be effective for
the early part of the returned record set, but I believe they don't page
through a bunch of records, they probably add search criteria). But for
reporting I will need to return all the records and this seems slow to me
(but it might be in line with what I get now; I will have to do some
benchmarking).
The application is a mixture of .net and asp and will soon have java.
So I am using the .net library for the .net pages and the ODBC driver for
the asp pages.
I did find using a view for the location join sped up the query a great
deal, I will have to see if there are other places I can use that thinking
(instead of joining on the associate table and its dependants I can just
join on a view of that data, etc).
Basically I have a view that does a join from location to district, region
and division tables. The old viwassoclist had those joined to the assoc
table in the viwassoclist, I changed it to use the view I created where the
tables were joined to the location table and in assoclist I just join to the
location view. This really made a huge difference in speed.
Regards, Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Dawid Kuroczko | 2005-04-18 14:19:37 | Re: immutable functions vs. join for lookups ? |
Previous Message | Dave Page | 2005-04-18 13:18:57 | Re: speed of querry? |