Re: [PERFORM] postgresql tuning with perf

We record like this: perf record -g -u enterprisedb We report like this: perf report -g -i perf.data Is this what you were looking for? Sorry, we are new to perf so we might be sharing something different as compared to what you asked. We already shared the SP code in the original post. Thanks

Re: [PERFORM] postgresql tuning with perf

Hi Pascal, Do you mean the sample program that acts as the application, do you want me to share that? I can do that, but I guess my post will get blocked. Yes, c1 is the PK. Pls see below: bmdb=# desc dept_new Table "public.dept_new" Column | Type | Modifiers +

Re: [PERFORM] postgresql tuning with perf

The language used for stored procedures is EDBSPL. Even if we dont use EDBSPL, and instead use PLPgPSQL, the performance is still the same. Thanks On 24 October 2017 at 03:29, Steve Atkins wrote: > > > On Oct 23, 2017, at 12:19 PM, Purav Chovatia wrote: > > > > Hello Ex

[PERFORM] postgresql tuning with perf

Hello Experts, We are trying to tune our postgresql DB using perf. We are running a C program that connects to postgres DB and calls very simple StoredProcs, one each for SELECT, INSERT & UPDATE. The SPs are very simple. *SELECT_SP*: CREATE OR REPLACE PROCEDURE query_dept_new(p1 IN numeric, p2 OU

Re: [PERFORM] 99% time spent in WAL wait events

Kindly ignore this post. It was an oversight - the wait times are in millisec and hence even if we manage to reduce these waits to 0, we will gain only 1000 msec of savings during a workload of 40min. Regards On 16 Oct 2017 7:04 pm, "Purav Chovatia" wrote: Hello, We are running wor

[PERFORM] 99% time spent in WAL wait events

Hello, We are running workload on a EDB Postgres Advanced Server 9.6 and we see that 99% of the time is spent on WAL wait events: *System Wait Information WAIT NAME COUNT WAIT TIME % WAIT --- wal flush 564552 298.789464

Re: [PERFORM] Stored Procedure Performance

Yes, there is some code to catch exceptions like unique constraint violation and no data found. Do you suggest we trying by commenting that part? btw, the dataset is a controlled one, so what I can confirm is we are not hitting any exceptions. Thanks On 11 October 2017 at 22:07, Adam Brusselback

Re: [PERFORM] Stored Procedure Performance

Thanks Pavel. Our SPs are not doing any mathematical calculations. Its mostly if-else, so I would expect good performance. On 11 October 2017 at 19:50, Pavel Stehule wrote: > > > 2017-10-11 15:59 GMT+02:00 Purav Chovatia : > >> Thanks Laurenz, am having a look at perf. >

Re: [PERFORM] Stored Procedure Performance

Thanks. We looked at pg_stat_statements and we see execution count & total time taken. But that still does not help me to identify why is it slow or what is taking time or where is the wait. btw, does pg_stat_statements add considerable overhead? Coming from the Oracle world, we are very used to

Re: [PERFORM] Stored Procedure Performance

ored Procs? Regards On 3 October 2017 at 20:24, Laurenz Albe wrote: > Purav Chovatia wrote: > > I come from Oracle world and we are porting all our applications to > postgresql. > > > > The application calls 2 stored procs, > > - first one does a few selects and

[PERFORM] Stored Procedure Performance

Hello, I come from Oracle world and we are porting all our applications to postgresql. The application calls 2 stored procs, - first one does a few selects and then an insert - second one does an update The main table on which the insert and the update happens is truncated before every performan