Re: [PERFORM] Performance bug in prepared statement binding in 9.2?

> This is why I'm asking them to run tests on 9.1. If 9.1 doesn't exhibit > this behavior, then customplan is liable to be at fault. 9.1 shows the same performance as 9.2. So it's not the custom plan thing. -- Josh Berkus PostgreSQL Experts Inc. http://pgexperts.com -- Sent via pgsql-perfo

Re: [PERFORM] Performance bug in prepared statement binding in 9.2?

Amit, > I think it might be because of choosing custom plan option due to which it > might be generating new plan during exec_bind_message(). > exec_bind_message()->GetCachedPlan()->choose_custom_plan(). If it chooses > custom plan, then it will regenerate the plan which can cause extra cost > o

Re: [PERFORM] Slow SELECT by primary key? Postgres 9.1.2

On Thu, May 30, 2013 at 10:22 AM, Igor Neyman wrote: >> -Original Message- >> From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- >> ow...@postgresql.org] On Behalf Of Merlin Moncure >> Sent: Thursday, May 30, 2013 11:14 AM >> To: John Mudd >> Cc: pgsql-performance@post

Re: [PERFORM] Slow SELECT by primary key? Postgres 9.1.2

I flushed the caches in an attempt to get meaningful results. I've seen complaints to previous posts that don't include clearing the caches. I agree this tends to be artificial in another direction. I will strive to come up with a more realistic test environment next time. Maybe performing many ra

Re: [PERFORM] Slow SELECT by primary key? Postgres 9.1.2

> -Original Message- > From: pgsql-performance-ow...@postgresql.org [mailto:pgsql-performance- > ow...@postgresql.org] On Behalf Of Merlin Moncure > Sent: Thursday, May 30, 2013 11:14 AM > To: John Mudd > Cc: pgsql-performance@postgresql.org > Subject: Re: [PERFORM] Slow SELECT by primary k

Re: [PERFORM] Slow SELECT by primary key? Postgres 9.1.2

On Mon, May 27, 2013 at 9:02 AM, John Mudd wrote: > Postgres 9.1.2 on Ubuntu 12.04 > > Any reason why a select by primary key would be slower than a select that > includes an ORDER BY? I was really hoping using the primary key would give > me a boost. > > I stopped the server and cleared the O/S c

Re: [PERFORM] Performance bug in prepared statement binding in 9.2?

On Thursday, May 30, 2013 5:45 AM Josh Berkus wrote: > Folks, > > I'm seeing what may be a major performance bug in BIND in 9.2.4. > > We have a client who has an application which uses > Tomcat+Hibernate+JDBC. They are in the process of upgrading this > application from 8.4.17 to 9.2.4. As par

Re: [PERFORM] Check Pointer

Thanks for the quick response. Below is the out put of Top Commnd. 3971 postgres 20 0 8048m 303m 301m S0 0.9 0:04.34 /usr/lib/postgresql/9.2/bin/postgres -D /var/lib/postgresql/9.2/main -c config_file=/etc/postgre 3972 postgres 20 0 66828 1820 708 S0 0.0 1:36.37 postgres: log

Re: [PERFORM] Check Pointer

On 30.05.2013 15:09, itishree sukla wrote: In our server Check pointer process is consuming 8 GB of memory, what could be the possible reason? Can any one please help. Are you sure you're measuring the memory correctly? The RES field in top output, for example, includes shared memory, ie. the

Re: [PERFORM] Check Pointer

Hi , Could you share the command, what you have used to confirm that, the checkpoint process is consuming 8GB. And also, please share the addition information like PostgreSQL version and the OS details. I am suspecting that, your shared_buffers value is 8GB, and the "top" command is showing the u

Re: [PERFORM] Check Pointer

On 5/30/13 8:09 AM, itishree sukla wrote: In our server Check pointer process is consuming 8 GB of memory, what could be the possible reason? Can any one please help. That process will eventually access all of shared_buffers, which shows as a shared memory block for that process. That's what

[PERFORM] Check Pointer

Hi all, In our server Check pointer process is consuming 8 GB of memory, what could be the possible reason? Can any one please help. Regards, Itishree