Re: [PERFORM] User concurrency thresholding: where do I look?

"Jignesh K. Shah" <[EMAIL PROTECTED]> writes: > Here is how I got the numbers.. > I had about 1600 users login into postgresql. Then started the run with > 500 users and using DTrace I started tracking Postgresql Locking "as > viewed from one user/connection". Echo statements indicate how many

Re: [PERFORM] User concurrency thresholding: where do I look?

Here is how I got the numbers.. I had about 1600 users login into postgresql. Then started the run with 500 users and using DTrace I started tracking Postgresql Locking "as viewed from one user/connection". Echo statements indicate how many users were active at that point and how was throughpu

Re: [PERFORM] Performance issue with 8.2.3 - "C" application

Looks like that was the problem - got a day under the belt now with the 8.2.4 rev and all is back to normal. Karl Denninger ([EMAIL PROTECTED]) http://www.denninger.net Karl Denninger wrote: Aha! BIG difference. I won't know for sure until the biz day tomorrow but the "first blush" look

Re: [PERFORM] Insert Statements Hanging

On Wednesday 25 July 2007 13:27, Pallav Kalva <[EMAIL PROTECTED]> wrote: > I am hoping "SELECT 1 FROM ONLY "provisioning"."account" x WHERE > "accountid" = $1 FOR UPDATE OF x" is causing the problem. If that is the > case why doesnt it show in the pg_stat_activity view ? or am I missing > somethin

[PERFORM] Insert Statements Hanging

Hi, I am having problems with some of the Insert statements in the prod database. Our client application is trying into insert some of the records and it is not going through , they are just hanging. They are running in a transaction and some how it is not telling us what is it waiting on . He

Re: [PERFORM] Simple select hangs while CPU close to 100%

In response to "Jozsef Szalay" <[EMAIL PROTECTED]>: > Our application is such that any update to the database is done by a > single session in a batch process using bulk load. The frequency of > these usually larger scale updates is variable but an update runs every > 2-3 days on average. > > Ori

Re: [PERFORM] Simple select hangs while CPU close to 100%

hello show me, please, output from vacuum verbose table Pavel 2007/7/25, Jozsef Szalay <[EMAIL PROTECTED]>: Our application is such that any update to the database is done by a single session in a batch process using bulk load. The frequency of these usually larger scale updates is variable bu

[PERFORM] Affect of Reindexing on Vacuum Times

I am wondering if reindexing heavily used tables can have an impact on vacuum times. If it does, will the impact be noticeable the next time I vacuum? Please note that I am doing vacuum, not vacuum full. I am on a FreeBSD 6.1 Release, Postgresql is 8.09 Currently I seeing a phenomenon where vacu

Re: [PERFORM] Simple select hangs while CPU close to 100%

Our application is such that any update to the database is done by a single session in a batch process using bulk load. The frequency of these usually larger scale updates is variable but an update runs every 2-3 days on average. Originally a plain VACUUM ANALYZE was executed on every affected tab

Re: [PERFORM] Simple select hangs while CPU close to 100%

In response to "Jozsef Szalay" <[EMAIL PROTECTED]>: > Hi Pavel, > > > Yes I did vacuum. In fact the only way to "fix" this problem is > executing a "full" vacuum. The plain vacuum did not help. I read over my previous reply and picked up on something else ... What is your vacuum _policy_? i.e

Re: [PERFORM] Simple select hangs while CPU close to 100%

In response to "Jozsef Szalay" <[EMAIL PROTECTED]>: > Hi Pavel, > > Yes I did vacuum. In fact the only way to "fix" this problem is > executing a "full" vacuum. The plain vacuum did not help. Based on the information, I would expect that this problem is the result of improper PG tuning, or inade

Re: [PERFORM] Simple select hangs while CPU close to 100%

The actual application does not have to perform this statement since, as you suggested; it keeps track of what got loaded. However, the table has to go thru a de-duplication process because bulk load is utilized to load the potentially large number (millions) of rows. All indexes were dropped for

Re: [PERFORM] Simple select hangs while CPU close to 100%

2007/7/25, Jozsef Szalay <[EMAIL PROTECTED]>: Hi Pavel, Yes I did vacuum. In fact the only way to "fix" this problem is executing a "full" vacuum. The plain vacuum did not help. Regards, Jozsef It's question if vacuum was done. Try vacuum verbose; Maybe your max_fsm_pages is too low and y

Re: [PERFORM] Simple select hangs while CPU close to 100%

Hi Pavel, Yes I did vacuum. In fact the only way to "fix" this problem is executing a "full" vacuum. The plain vacuum did not help. Regards, Jozsef -Original Message- From: Pavel Stehule [mailto:[EMAIL PROTECTED] Sent: Sunday, July 22, 2007 10:53 AM To: Jozsef Szalay Cc: pgsql-perfor

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

"Simon Riggs" <[EMAIL PROTECTED]> writes: > On Wed, 2007-07-25 at 10:09 -0400, Merlin Moncure wrote: >> >> just a small 'me too' here, the RI penalty seems higher than it should >> be...especially when the foreign key table is very small, and I can >> see how this would impact benchmarks. > > An

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

On Wed, 2007-07-25 at 10:09 -0400, Merlin Moncure wrote: > On 7/25/07, Simon Riggs <[EMAIL PROTECTED]> wrote: > > > > Should you get the chance I would appreciate a comparative test for > > TPC-E. > > > > 1. Normal TPC-E versus > > 2. TPC-E with all FKs against Fixed tables replaced with CHECK( co

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

On 7/25/07, Simon Riggs <[EMAIL PROTECTED]> wrote: On Fri, 2007-07-20 at 10:03 -0700, Josh Berkus wrote: > Jim, > > > Has anyone benchmarked HEAD against 8.2? I'd like some numbers to use in > > my OSCon lightning talk. Numbers for both with and without HOT would be > > even better (I know we've

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

On Wed, 2007-07-25 at 15:07 +0200, Mario Weilguni wrote: > Am Mittwoch 25 Juli 2007 schrieb Simon Riggs: > > I have reasonable evidence that Referential Integrity is the major > > performance bottleneck and would like some objective evidence that this > > is the case. > > Just curious, will 8.3 st

Re: [PERFORM] index over timestamp not being used

On 2007-07-25 Mario Weilguni wrote: > Am Dienstag 24 Juli 2007 schrieb Tom Lane: >>> I thought the to_char/to_date/to_timestamp functions were intented >>> for this purposes >> >> No, they're intended for dealing with wacky formats that the regular >> input/output routines can't understand or produ

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

Am Mittwoch 25 Juli 2007 schrieb Simon Riggs: > I have reasonable evidence that Referential Integrity is the major > performance bottleneck and would like some objective evidence that this > is the case. Just curious, will 8.3 still check FK constraints (and use locks) even if the referencing col

Re: [PERFORM] index over timestamp not being used

Am Dienstag 24 Juli 2007 schrieb Tom Lane: > > I thought the > > to_char/to_date/to_timestamp functions were intented for this purposes > > No, they're intended for dealing with wacky formats that the regular > input/output routines can't understand or produce. Really? I use them alot, because of

Re: [pgsql-advocacy] [PERFORM] 8.2 -> 8.3 performance numbers

On Fri, 2007-07-20 at 10:03 -0700, Josh Berkus wrote: > Jim, > > > Has anyone benchmarked HEAD against 8.2? I'd like some numbers to use in > > my OSCon lightning talk. Numbers for both with and without HOT would be > > even better (I know we've got HOT-specific benchmarks, but I want > > compl

Re: [PERFORM] Table Statistics with pgAdmin III

Campbell, Lance wrote: All of the fields are zero except for the three I listed in my posting. Do you have the stats collector enabled, and row & block level stats turned on? Regards, Dave. ---(end of broadcast)--- TIP 4: Have you searched our

Re: [PERFORM] multicolumn index column order

On Jul 25, 2:14 am, Lew <[EMAIL PROTECTED]> wrote: > > How about two indexes, one on each column? Then the indexes will cooperate > when combined in a WHERE clause. > > > I don't believe the index makes a semantic differenc

Re: [PERFORM] Performance issue with 8.2.3 - "C" application

"Karl Denninger" <[EMAIL PROTECTED]> writes: > Not sure where to start here. It appears that I'm CPU limited and the problem > may be that this is a web-served application that must connect to the Postgres > backend for each transaction, perform its queries, and then close the > connection down -