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
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 |
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 |