Re: Performance large tables.

From: Bruno Wolff III <bruno(at)wolff(dot)to>
To: Benjamin Arai <barai(at)cs(dot)ucr(dot)edu>
Cc: Martijn van Oosterhout <kleptog(at)svana(dot)org>, pgsql-general(at)postgresql(dot)org
Subject: Re: Performance large tables.
Date: 2005-12-11 15:41:27
Message-ID: 20051211154127.GA27484@wolff.to
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Please start new threads to ask unrelated questions, rather than replying
to an existing thread. This makes the archives less useful, and may keep
people from seeing your question.

On Sat, Dec 10, 2005 at 15:37:01 -0800,
Benjamin Arai <barai(at)cs(dot)ucr(dot)edu> wrote:
> To be more specific, there are two types of commands that are run on
> the system. There are application commands that do all different types
> of joins and etc but for the most part are fast enough to meet user
> expectations. On the other hand there is a weekly update (This is the
> problem) that updates all of the modified records for a bunch of
> finacial data such as closes and etc. For the most part they are
> records of the type name,date,value. The update currently takes almost
> two days. The update does deletions, insertion, and updates depending
> on what has happened from the previous week.
>
> For the most part the updates are simple one liners. I currently commit
> in large batch to increase performance but it still takes a while as
> stated above. From evaluating the computers performance during an
> update, the system is thrashing both memory and disk. I am currently
> using Postgresql 8.0.3.
>
> Example command "UPDATE data where name=x and date=y;".

Another possibility is that foreign key checks may be slowing things down.
You may need to create some indexes on referencing tables if you are doing
deletes (or updates which change the key) in referenced tables.

Finding out more about which queries are slow and what plans they are using
is a good first step.

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Bruno Wolff III 2005-12-11 16:00:39 Re: PL/pgSQL : notion of deferred execution
Previous Message Frank van Vugt 2005-12-11 15:31:59 PL/pgSQL : notion of deferred execution