Re: [PERFORM] Terrible Write Performance of a Stored Procedure

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Brian Troutwine <goofyheadedpunk(at)gmail(dot)com>
Cc: PostgreSQL General <pgsql-general(at)postgresql(dot)org>
Subject: Re: [PERFORM] Terrible Write Performance of a Stored Procedure
Date: 2009-06-29 15:00:36
Message-ID: b42b73150906290800p130429d4i1d10a7ed8d27628b@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general pgsql-performance

On Fri, Jun 26, 2009 at 4:36 PM, Brian
Troutwine<goofyheadedpunk(at)gmail(dot)com> wrote:
>> *) use indexes to optimize where and join conditions.  for example,
>> update yadda set yadda where foo = bar, make sure that there is an
>> index on foo.  As alan noted this is almost definitely your problem.
>
> To my knowledge, I have. amazon_items.isbn does not have an index but
> it is not used, unless I'm overlooking something, in a where
> condition. item_details.isbn is and does, however.
>
>> *) use varchar, not char (always).
>
> Why?
>

char(n) included the padding up to 'n' both on disk and in data
returned. It's slower and can be wasteful.

Did you figure out your issue? I'm pretty sure its an index issue or
some other basic optimization problem.

merlin

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Tom Lane 2009-06-29 15:04:45 Re: Slony-I timezone setting
Previous Message Merlin Moncure 2009-06-29 14:58:06 Re: pasting into psql garbles text

Browse pgsql-performance by date

  From Date Subject
Next Message Hartman, Matthew 2009-06-29 15:01:57 Re: Utilizing multiple cores in a function call.
Previous Message Kevin Grittner 2009-06-29 14:53:33 Re: random slow query