Fw: [GENERAL] identifying performance hits: how to ???

From: davidb(at)vectormath(dot)com
To: <pgsql-general(at)postgresql(dot)org>
Subject: Fw: [GENERAL] identifying performance hits: how to ???
Date: 2000-01-12 16:26:16
Message-ID: 009f01bf5d19$c1665d20$0602010a@bullwinkle.vectormath
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

I forgot the punch line:

If you are requiring some sort of combinatorial operation, you might
consider restructuring your query or doing some of the query's work
programmatically.

David Boerwinkle
-----Original Message-----
From: davidb(at)vectormath(dot)com <davidb(at)vectormath(dot)com>
To: Robert Wagner <rwagner(at)siac(dot)com>; pgsql-general(at)postgresql(dot)org
<pgsql-general(at)postgresql(dot)org>
Cc: squires(at)com(dot)net <squires(at)com(dot)net>
Date: Wednesday, January 12, 2000 10:21 AM
Subject: Re: [GENERAL] identifying performance hits: how to ???

>By asking about missing something fundamental, you have invited
>less-than-expert feedback (i.e. feedback from me).
>
>'adding a record doubles the retrieval time' makes it sound as though
>somewhere in your query to populate the grid control you are requiring a
>combinatorial operation (that is, "compare every record in table A with
>every record in table B"). This, of course, assumes that there is some
>discrepancy between what you are running on Postgres and what you tried on
>Windows NT (MS-SQL?).
>
>David Boerwinkle
>-----Original Message-----
>From: Robert Wagner <rwagner(at)siac(dot)com>
>To: pgsql-general(at)postgresql(dot)org <pgsql-general(at)postgresql(dot)org>
>Cc: squires(at)com(dot)net <squires(at)com(dot)net>
>Date: Wednesday, January 12, 2000 9:56 AM
>Subject: [GENERAL] identifying performance hits: how to ???
>
>
>>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
>>
>>
>>
>>************
>>
>

Browse pgsql-general by date

  From Date Subject
Next Message Jim Mercer 2000-01-12 16:55:03 Re: [GENERAL] identifying performance hits: how to ???
Previous Message Cory Kempf 2000-01-12 16:23:35 Re: postgresql installation