[PERFORM] Unexpected slow query time when joining small table with large table

2013-11-11 Thread Ryan LeCompte
Hello all! I'm new to postgresql, so please bear with me. First of all, I have the following settings enabled in my postgresql.conf file: shared_buffers = 2GB work_mem = 2GB maintenance_work_mem = 4GB checkpoint_segments = 50 random_page_cost = 3.5 cpu_tuple_cost = 0.1 effective_cache_size = 48GB

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Jeff Janes
On Mon, Nov 11, 2013 at 3:28 PM, Jim Nasby wrote: > On 11/11/13 4:57 PM, Jeff Janes wrote: > > On Mon, Nov 11, 2013 at 1:57 PM, Jim Nasby > jna...@enova.com>> wrote: >> Btree indexes have special code that kill index-tuples when the >> table-tuple is dead-to-all, so only the first such query aft

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Jim Nasby
On 11/11/13 4:57 PM, Jeff Janes wrote: On Mon, Nov 11, 2013 at 1:57 PM, Jim Nasby mailto:jna...@enova.com>> wrote: Btree indexes have special code that kill index-tuples when the table-tuple is dead-to-all, so only the first such query after the mass deletion becomes vacuum-eligible should be s

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Jeff Janes
On Mon, Nov 11, 2013 at 1:57 PM, Jim Nasby wrote: > > explain (analyze,buffers) select min(insert_time) from > cnu_stats.page_hits_raw ; > > QUERY PLAN > > >

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Daniel Farina
On Mon, Nov 11, 2013 at 1:57 PM, Jim Nasby wrote: > We do run a regular process to remove older rows... I thought we were > vacuuming after that process but maybe not. Could be a long query, idle-in-transaction, prepared transaction, or hot standby feedback gone bad, too. -- Sent via pgsql-per

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Jim Nasby
On 11/11/13 3:51 PM, Daniel Farina wrote: On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby wrote: Postgres 9.1.9. explain analyze select min(insert_time) from cnu_stats.page_hits_raw ; I checked and there were no un-granted locks... but I have a hard time believing it actually too 257 seconds to get

Re: [PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Daniel Farina
On Mon, Nov 11, 2013 at 1:48 PM, Jim Nasby wrote: > Postgres 9.1.9. > > explain analyze select min(insert_time) from cnu_stats.page_hits_raw ; > > QUERY PLAN > --

[PERFORM] Horrific time for getting 1 record from an index?

2013-11-11 Thread Jim Nasby
Postgres 9.1.9. explain analyze select min(insert_time) from cnu_stats.page_hits_raw ; QUERY PLAN

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread Jeff Janes
On Thu, Nov 7, 2013 at 2:13 AM, Евгений Селявка wrote: > All my sar statistics > ... > sar -u ALL > 11:40:02 AM CPU %usr %nice %sys %iowait%steal > %irq %soft%guest %idle > 01:15:01 PM all 8.57 0.00 1.52 1.46 0.00 > 0.00 0.05

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread Sergey Konoplev
On Mon, Nov 11, 2013 at 8:14 AM, Scott Marlowe wrote: > well you can hopefully reduce connections from jdbc pooling then. The > fact that the connections are idle is good. > > The problem you run into is what happens when things go into > "overload" I.e. when the db server starts to slow down, mor

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread Sergey Konoplev
On Sun, Nov 10, 2013 at 11:48 PM, Евгений Селявка wrote: > Sergey, yes this is all of my kernel setting. I don't use THP intentionally. > I think that i need a special library to use THP with postgresql like this > http://code.google.com/p/pgcookbook/wiki/Database_Server_Configuration. This > i

Re: [PERFORM] Planner performance extremely affected by an hanging transaction (20-30 times)?

2013-11-11 Thread Tom Lane
Andres Freund writes: > Also, this really isn't going to fix the issue discussed here - this was > just about the additional ProcArrayLock contention. I don't think it > would change anything dramatical in your case. All of these proposals are pretty scary for back-patching purposes, anyway. I t

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread k...@rice.edu
On Mon, Nov 11, 2013 at 09:14:43AM -0700, Scott Marlowe wrote: > On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка > wrote: > > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections > > from components wich use jdbc. I don't think that this is a good idea use > > pgbouncer, be

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread Scott Marlowe
On Mon, Nov 11, 2013 at 1:09 AM, Евгений Селявка wrote: > Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections > from components wich use jdbc. I don't think that this is a good idea use > pgbouncer, because our application using spring framework which using jdbc > and prepar

Re: [PERFORM] Size of IN list affects query plan

2013-11-11 Thread Jan Walter
Thanks for your comments. On 8.11.2013 15:31, Tom Lane wrote: AFAICT, the reason the second plan is slow is the large number of checks of the IN list. The planner does account for the cost of that, but it's drastically underestimating that cost relative to the cost of I/O for the heap and inde

Re: [PERFORM] postgresql recommendation memory

2013-11-11 Thread Евгений Селявка
Scott hi, i calculate all of my jdbc pool size. Maximum is 300 connections from components wich use jdbc. I don't think that this is a good idea use pgbouncer, because our application using spring framework which using jdbc and prepared statement. I try to talk with our developer about disabling pr