identifying performance hits: how to ??? - Mailing list pgsql-general

From Robert Wagner
Subject identifying performance hits: how to ???
Date
Msg-id 85256864.00542073.00@SIAC_NOTES_001.wisdom.siac.com
Whole thread Raw
Responses Re: [GENERAL] identifying performance hits: how to ???  (Karl DeBisschop <kdebisschop@range.infoplease.com>)
Re: [GENERAL] identifying performance hits: how to ???  (The Hermit Hacker <scrappy@hub.org>)
Re: [GENERAL] identifying performance hits: how to ???  (Peter Eisentraut <peter_e@gmx.net>)
List pgsql-general
Hello All,

Anyone know if read performance on a postgres database decreases at an
increasing rate, as the number of stored records increase?

This is a TCL app, which makes entries into a single, table and from time
to time repopulates a grid control.  It must rebuild the data in the grid
control, because other clients have since written to the same table.

It seems as if I'm missing something fundamental... maybe I am... is some
kind of database cleanup necessary?   With less than ten records, the grid
populates very quickly.  Beyond that, performance slows to a crawl, until
it _seems_ that every new record doubles the time needed to retrieve the
records.  My quick fix was to cache the data locally in TCL, and only
retrieve changed data from the database.  But now as client demand
increases, as well as the number of clients making changes to the table,
I'm reaching the bottleneck again.

The client asked me yesterday to start evaluating "more mainstream"
databases, which means that they're pissed off.  Postgres is fun to work
with, but it's hard to learn about, and hard to justify to clients.

By the way, I have experimented with populating the exact same grid control
on Windows NT, using MS Access (TCL runs just about anywhere).  The grid
seemed to populate just about instantaneously.  So, is the bottleneck in
Unix, in Postgres, and does anybody know how to make it faster?

Cheers,
Rob



pgsql-general by date:

Previous
From: Sarah Officer
Date:
Subject: Re: [GENERAL] How do you live without OUTER joins?
Next
From: Bruce Momjian
Date:
Subject: Simulating an outer join