> -----Original Message-----
> From: pgsql-performance-owner@postgresql.org
> [mailtogsql-performance-owner@postgresql.org] On Behalf Of
> Joel Fradkin
> Sent: 18 April 2005 14:02
> To: PostgreSQL Perform
> Subject: FW: [PERFORM] speed of querry?
>
> Another odd thing is when I tried turning off merge joins on
> the XP desktop
> It took 32 secs to run compared to the 6 secs it was taking.
> On the Linux (4proc box) it is now running in 3 secs with the
> mergejoins
> turned off.
>
> Unfortunately it takes over 2 minutes to actually return the
> 160,000+ rows.
> I am guessing that is either network (I have gig cards on a
> LAN) or perhaps
> the ODBC driver (using PGADMIN III to do the select).

pgAdmin III uses libpq, not the ODBC driver.

Regards, Dave

---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to majordomo@postgresql.org)

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


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

http://archives.postgresql.org