From: | "Dave Dutcher" <dave(at)tridecap(dot)com> |
---|---|
To: | "'Shiva Raman'" <raman(dot)shivag(at)gmail(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: High CPU load on Postgres Server during Peak times!!!! |
Date: | 2009-09-24 16:08:15 |
Message-ID: | 11E13D6A17F84B848770849770B08FEE@tridecap.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
>From: Shiva Raman
>Subject: Re: [PERFORM] High CPU load on Postgres Server during Peak
times!!!!
>
>Andy Colson Wrote : ,
>>Eww. I think that's bad. A connection that has a transaction open will
cause lots of row versions,
>>which use up ram, and make it slower to step through the table (even with
an index). You really need
>>to fix up your code and make sure you commit transactions. (any statement
(select, insert, update) will
>>start a new transaction that you need to explicitly commit).
>
>With reference to this suggestion by Andy Colson, we checked the
application code and found that only
>INSERT, UPDATE has COMMIT and SELECT has no commit, We are using a lot of
"Ajax Suggest" in the all
>the forms accessed for fetching the data using SELECT statements which are
not explicitly committed.
>We have started updating the code on this.
You need a COMMIT for every BEGIN. If you just run a SELECT statement
without first beginning a transaction, then you should not end up with a
connection that is Idle in Transaction. If you are beginning a transaction,
doing a select, and then not committing, then yes that is a bug.
Dave
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2009-09-24 16:26:08 | Re: Use of sequence rather than index scan for one text column on one instance of a database |
Previous Message | Karl Denninger | 2009-09-24 15:48:34 | Re: High CPU load on Postgres Server during Peak times!!!! |