> 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
