Re: What kind of performace can I expect and how to measure? - Mailing list pgsql-performance

From Merlin Moncure
Subject Re: What kind of performace can I expect and how to measure?
Date
Msg-id 6EE64EF3AB31D5448D0007DD34EEB34101AF16@Herge.rcsinc.local
Whole thread Raw
In response to What kind of performace can I expect and how to measure?  ("Joost Kraaijeveld" <J.Kraaijeveld@Askesis.nl>)
List pgsql-performance
> 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






pgsql-performance by date:

Previous
From: Tom Lane
Date:
Subject: Re: No index usage with "left join"
Next
From:
Date:
Subject: Re: SSD Drives