> Hi Merlin, > > > The 9206 ms time is what the database actually spent > > gathering the data and sending it to you. This is non-negotiable unless > you bump up > > hardware, etc, or fetch less data. This time usually scales linearly > > (or close to it) with the size of the dataset you fetch. > > > > The 40638 ms time is pgAdmin putting the data in the grid. This time > So it take PostgreSQL 9206 ms to get the data AND send it to the client. > It than takes PGAdmin 40638 ms to display the data?
That is correct. This is not a problem with pgAdmin, or postgres, but a problem with grids. Conceptually, SQL tables are an in an unordered, infinite space and grids require an ordered, finite space. All 4GLs and data managers have this problem. The real solution is to refine your query in a meaningful way (80k rows is more than a human being can deal with in a practical sense). If you can't do that, install an arbitrary limit on the result set where performance breaks down, could be 10-100k depending on various factors. To simulate a finite, ordered, dataset, pgAdmin takes all the result data and puts it in GUI controls are not designed to hold 100k rows data...this is a design compromise to allow editing. Merlin ---------------------------(end of broadcast)--------------------------- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly